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Introduction 


Technical reports normally concern the results of research project, not their plans. 
Nevertheless, we believe it important sometimes that new ideas, reflected in a proposal to carry 
out a research project, be exposed to the scrutiny and suggestions of our colleagues. This serves 
both to let them teach us valuable lessons in criticizing our plans and (we hope) to sway them 
toward our views on what constitutes fruitful research directions. This report contains most of 
the text of a proposal we submitted in March, 1994 to ARPA in response to BAA 94-13, for the 
Health Information Infrastructure Program. This report differs from the proposal only in its 
organization and in omitting budgetary and administrative details. To a large extent, we have 
retained the language typical of proposals, and hope for the reader's patience with its tone. 

The mid-1990's promise to usher in an era of comprehensive medical record keeping and 
the beginning of intelligent computer-based agents that can exploit such records to improve the 
quality or reduce the cost of health care. Most current efforts to achieve these goals center on 
putting in place ideas that have been proposed over the past several decades, but made more 
feasible by declining costs of computing and made more urgent by our society's determination 
to study the outcomes of medical interventions and to restrict funding to only those 
interventions that seem most clearly worthwhile. Such efforts typically center on building 
clinical information systems for hospitals, clinics, individual health care providers, insurers, 
and government reviewers. 

Our proposal comes from an attempt to rethink the sources of possible leverage in improving 
health care, and focusing on the role of the patient in maintaining his or her health and 
responding to disease. Thus, we plan to build systems to support the health information needs of 
the consumers of health care rather than its providers. This shift of focus will, we hope, make 
possible dramatic improvements in health maintenance and health care delivery, by making 
useful information available in a timely manner to the patient. The shift also allows us to look 
at many of the technical issues of how to collect, maintain and interpret comprehensive health 
information from a very different viewpoint, and might therefore speed the advance of medical 
informatics. 

The review of this proposal was favorable, and although we have as of now no assurance of 
funding, we are very much committed to pursuing the project and exploring its societal and 
technical consequences. 

Peter Szolovits 
May 1994 
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Part I 


Lifetime Patient-Centered Health Information Systems 


Current health information systems are built for the convenience of health care providers and 
consequently yield fragmented patient records in which medically relevant lifelong 
information is sometimes incomplete, incorrect, or inaccessible. We are constructing 
information systems centered on the individual patient instead of the provider, in which a set of 
“guardian angel” (GA) software agents integrates all health-related concerns, including 
medically-relevant legal and financial information, about an individual (its “subject”). This 
personal system will help track, manage, and interpret the subject’s health history, and offer 
advice to both patient and provider. Minimally, the system will maintain comprehensive, 
cumulative, correct, and coherent medical records, accessible in a timely manner as the subject 
moves through life, work assignments, and health care providers. Each GA is an active 
process that performs several important functions: it collects patient data; it checks, interprets, 
and explains to the subject medically-relevant facts and plans; it adapts its advice based on the 
subject’s prior experiences and stated preferences; it performs “sanity checks” on both medical 
efficacy and cost-effectiveness of diagnostic conclusions and therapeutic plans; it monitors 
progress; it interfaces to software agents of providers, insurers, etc.; and it helps educate, 
encourage, and inform the patient. All this serves to improve the quality of medical decision- 
making, increase patient compliance, and minimize iatrogenic disease and medical errors. 


The “Guardian Angel” Concept 


We propose a major shift of primary focus away from information systems based on the 
hospital, clinic and medical practice, to one based on the individual. Such a system, which we 
call “Guardian Angel” (GA), integrates over a lifetime all health-related information about an 
individual (its “subject”), thus providing, at minimum, a comprehensive medical record that is 
often virtually impossible to reconstruct in a timely manner as the subject moves through life 
and work assignments. But GA is to be not merely a passive repository of information, but an 
active process that: 


(a) engages in data collection, sometimes by interacting with the subject and sometimes 
by automatic tracking and recording of instruments, 


(b) monitors the progress of medical conditions and the effects of therapy with respect to 
expectations, and checks for side effects, 


(c) interprets facts and medically-related plans and helps explain them to the 
individual, 


(d) allows the patient to customize therapy plans within bounds established by care 
providers, giving the patient “ownership” of his or her therapy, 


(e) performs “sanity checks” on the appropriateness of diagnostic conclusions and 
therapeutic plans, 


(f) contains some understanding of the subjects’ preferences, represents these in a broad 
range of negotiations with other systems, including setting therapeutic guidelines 
and scheduling appointments, and also uses these in structuring interactions 
between GA and the patient, 


(g) interfaces to information systems used by care providers, insurers, researchers, etc., 
to provide access to personal medical history information as authorized by the 
individual, and 


(h) provides patient education functions, including access to general and specialized 
medical encyclopedias, and explanations of diagnostic findings and therapy plans 
specific to the individual, 


(i) implements patient reminding and alerting functions, including reminders of 
scheduled therapy, medications and appointments, integrating these with personal 
scheduling tools, 
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(j) provides patient support functions such as contacts with support groups and other 
patients, queries to pharmaceutical companies, government agencies, etc. 


We believe, with many others, that active monitoring of accurate and comprehensive 
information about an individual’s lifetime medical history can greatly improve the quality of 
medical decision making for that person, reduce errors in health care, and allow people to 
make better personal decisions and commitments about their care.t Although experimental 
evidence to support this widely-held view is scant, recent reports in the areas of diabetes 
[DCCT 93, Lask93] and hypertension management both strongly indicate the value of active, 
continual management. 

In addition, we believe that there are dramatic improvements to be gained in both the 
effectiveness and the efficiency of health care if we can empower the user to take a much more 
active role in monitoring his or her own health status and care, and to take greater 
responsibility for making informed and guided decisions concerning that care. 

Principal benefits for doctors and other health-care providers include access to accurate, 
comprehensive data, the opportunity to be alerted to changes in the patient’s health that are either 
dangerous in themselves or deviate from an expected course of therapy, and the ability to 
communicate reliably with the patient. 

Although in the long run we envision GA as a routine health assistant for everyone, 
whether they are ill or well, in the short term it will be easier to apply the architecture as 
adapted for high-intensity medical interventions, for specific populations of patients who are 
undergoing active and complex therapy. In such circumstances, some of the monitoring of that 
therapy can be offloaded to the patient, with the help of GA, making the patient, the "human in 
the loop". For example, patients with chronic conditions such as diabetes can help to monitor 
and adjust their own care, and the ambulatory patient undergoing acute care such as 
chemotherapy may be able to judge certain aspects of his or her own care and tune them, with 
the aid of GA, for best results. GA could also help make possible the scheduling of visits to the 
care provider based on the patient’s actual response to care rather than on a general schedule. 
Most uses of GA could benefit greatly from the development and deployment of small, non- 
invasive sensors that can autonomously and continually monitor characteristics of the patient 
that are of vital concern. 


Architecture for “Guardian Angels” 


The objective of current medical information systems is to record and use only limited classes 
of information tailored to the operations of specific organizations. We propose to develop a 
highly flexible information flow architecture for Guardian Angels, one that permits variation 
of the timing, hardware and functionality of computations as the patient’s situation permits. 
GAs will run on a wide and evolving range of hardware, initially personal digital assistants 
(PDA's), personal computers (PC’s) or workstations, and eventually credit-card or dogtag-sized 
portable computers. They will employ distributed networked facilities to acquire and deliver 
information, relevant software modules, and access to specialized services, and to provide 
secure and reliable backup. We will also develop an extensible ontology for medical 
knowledge adequate to capturing patient and provider data, using the UMLS 
metathesaurus[UMLS91] as a point of departure, and an interchange language based on this 
ontology and on ARPA efforts such as KIF [Gene92] and the KQML [Baal94] interchange 
mechanisms. 


1For example, investigators have been able to demonstrate early detection of disorders such 
as malnutrition, tumor-associated acquired growth hormone deficiency, or inflammatory 
disease increases the likelihood of earlier, less costly intervention and with lesser long term 
morbidity [Bith92]. 

Another group has shown that tracking the longitudinal health status of children at risk has 
been recognized as an important tool in improving the health status of these underprivileged 
children [WilI92]. 
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Guardian Angel Interactions and Interoperations 


Current provider-oriented medical information systems do little to facilitate the intelligent use 
of health care resources by patients and by other organizations. We are designing the GA 
architecture to facilitate (within strict bounds of confidentiality) a wide variety of interactions 
with other software agents, including interactions aimed at scheduling medical procedures, 
polling by public health authorities to detect or delineate epidemics or contaminations, 
facilitating drug “recalls”, providing access to information infrastructure resources, and 
enabling patient support groups. 


Experimental Guardian Angel Applications 


We plan to apply the GA concept to creation of a small number of prototype systems for use by 
narrowly-defined patient populations who normally require relatively high-intensity out-patient 
care. With our partners, we are selecting among the following medical conditions: insulin- 
dependent diabetes, hypertension, angina, chronic anticoagulation, chronic renal disease, and 
pulmonary disease (COPD). These applications will also provide us a testbed in which to 
investigate both technical aspects of the system and the efficacy of its application to these 
particular populations of patients, and will provide a natural locus of collaboration among the 
participants. 


Example Scenario 


The following extended scenario illustrates our vision of the kinds of life-long patient-centered 
care that the GA concept can foster. The scenario (due to Dr. Kohane) assumes a specific type of 
hardware and communication architecture that is just one of many possibilities we plan to 
explore, but it does suggest the functionality we seek: 

Abby Kaye is a 14 year old girl who has had insulin-dependent diabetes mellitus for the 
last five years. Two years ago she began to measure her blood glucose and administer insulin 
without direct parental supervision. She has recently been enrolled as a participant in the 
Guardian Ange program. 

She wakes this morning, measures her blood sugar which is 180 mg/dl. This is 
automatically downloaded into the PDA which is connected to he: glucometer. GA_PDA stores 
an internal note to itsdf to renind Abby tonight that her blood sugar has been greater than 150 
mg/ dl before breakfast for 5 out of the last 7 days. Perhaps she should increase her nighttime 
dose of long acting (NPH) insulin? However, Abby is about to give her morning dose and 
GA_PDA does not distract her with this information at this time 

Abby is uncertain what insulin dose to give this morning as she has a double session 
dance class at 10:00 and she renembers all too wd! that she has had mild hypoglycemic 
symptoms towards the end of even single session dance classes. She draws an exercise symbol 
spanning 10 to 11:30 on her daily schedule on the GA_PDA interface and then selects the Advise 
Dose icon. The GA_PDA informs her that she can either keep the dose unchanged if she thinks 
she can manage a double carbohydrate snack before the dance class or she can reduce her 
morning dose of insulin by two units of short acting (regular) insulin. 

Two weeks later, Abby’s morning blood sugars have continued to climb and they are in 
the mid 200’s. Abby has not modified the GA_PDA default authorization to communicate with 
her parents’ desk-top computer. Therefore when according to schedule, the weekly blood 
sugars are uploaded by the GA_PDA component to the GA_home_computer component this 
worrisome trend is displayed to the parents. The GA_home_computer makes several 
suggestions as to how to modify the nightly NPH. If the parents do not feel comfortable 
following these suggestions, they are given several options for communications with the health- 
care providers including electronic mail with attached measurenents, directions for paging or 
an emergency phone number. If they are comfortable with the suggestions, then the recent 
data along with the alert are uploaded during the routine daily modem connection of GA_ 
home_computer with the GA_hospital_ process running on the hospital’s information system. 

Five months later: Abby has just come back from school upset because one of her 
friends teased her about becoming chubby. She steps on the bathroom scale and notes her 
weight; she has gained 10 pounds since her last doctor visit 4 months ago. She has already tried 
skipping her snacks but that leaves her feding awful from hypoglycenia (and even hungrier) 
subsequently. Perhaps, the GA_PDA can help. She taps on the die icon for advice The 
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GA_PDA is aware of several unexplained instances of hypoglycemia in the past month. The 
pattern of insulin dosing and recorded periods of exercise makes it most likey that these 
hypoglycemic episodes are due to skipped snacks. The GA_PDA makes a note to itself to use 
the opportunity of a query about diet to ask her at the end of the interaction whether she has 
been missing snacks and to warn her about the dangers. The GA _PDA is also aware of the 
heights and weights obtained at the doctor’s office in the last two visits (and downloaded from 
the IHIS by the GA_hospital_process to the GA_home_computer and then to the GA_PDA) 
and recognizes that Abby has indeed an increased weight for height over the past visits. 
GA_PDA asks Abby if she would like to review her meals and snacks for the past days as wall 
as go over her favorite foods. She selects from GA_PDA's large store of food types in quickly 
generating this description. GA_PDA then identifies the highest caloric items in her diet and 
proposes several lower calorie substitutions. This information is also passed along to Abby's 
parents via the GA_home computer along with an optional shopping list for the grocery store 

The next day, GA_PDA asks Abby if she would be interested in joining a group of 
children with diabetes to discuss the problems and difficulties of managing diabetes. The 
discussion can take place via the GA_PDA or GA_home computer which provides Abby with 
an interface to her peers over the Internet. Eventually Abby meets some of her Internet group 
friends at a summer diabetes camp. The discussion group become a way for them to keep in 
touch during the rest of the year when they live in different cities. Abby’s parents also use the 
GA_home_computer to stay in touch with other parents of children with diabetes and to 
remain abreast of any devdopments in research which might make diabetes easier to manage. 

Two months later: Abby’s father realizes that next week Abby will be performing with 
her entire dance class for a school performance. However, this performance occurs the same 
day as a scheduled visit with Abby’s endocrinologist. Abby's father goes to the weekly schedule 
view of the GA_home_ computer and cancds the endocrinologist visit. The GA_home_computer 
asks him if he wants to reschedule (he does) and then negotiates with the hospital scheduling 
system (via the GA_hospital_ process) two possible appointments for Abby in the coming 
month. After one is selected, the GA_hospital_process sends appropriate notifications to the 
hospital-based care providers. 

Another month has passed. After speaking with her endocrinologist during the last 
clinic visit, Abby was pleased to hear that her average blood sugar, indirectly measured from 
an assay of glycosylated hemoglobin, had fallen since the previous visit. She resolves to build 
upon this progress by “tightening” the control of her blood sugar. However, the GA notes that 
there has been a downward trend in her prelunch and predinner blood sugars and if it 
continues she will become dangerously hypoglycemic. It suggest that she decrease her morning 
insulin dose On their last interaction on die, the GA_PDA became aware that Abby was 
already ingesting too many calories, so it does not suggest any increase in snacks. Despite this 
suggestion, Abby does not decrease her dose of insulin. 

The next day, before the GA_PDA has a chance to upload this information to 
GA_home computer, Abby goes to school. She checks her blood glucose early, at 11:00 a.m. 
because she is feding abdominal cramps and weak. The glucometey communicates the value 
of 22 mg/dl back to the GA_ PDA. TheGA_PDA immediatedy makes a loud sound and displays 
on its screen a request for Abby to drink orange juice or eat a fruit or candy. When Abby does 
not acknowledge the alert after two minutes, GA_PDA sends a wiredess message to 
GA_home computer. If there is no response, it also sends a message to GA_hospital_process. 
Both GA instances have as thar first priority notifying the parents and school care takers. The 
diabetes nurse practitioner is paged with a message if none of the GA instances have received 
any acknowledgment from humans. 

In fact, Abby had not passed out but had found a candy bar. She was too miserable to 
work with the GA_PDA and therefore was only able to acknowledge after 3 minutes. The 
GA_PDA then sends a reassuring notation to the othe’ GA instances. The diabetes nurse 
practitioner has a tdephone conversation with Abby's parents about the need to moderate her 
target blood sugar levds. 

Six months later the desktop computer running GA_home_ computer has a serious disk 
crash. All data is lost without local backups. After reinitializing the disk, the GA software is 
reinstalled and the GA_home_computer automatically rebuilds its data structures after a brief 
communication with GA_hospital_process (for the exhaustive long-term record) and with 
GA_PDA for the most recent data. 
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Two months later: GA_home_computer identifies a cyclic risein blood sugars that has 
been occurring with periodicity of 30 to 45 days. The rises last 4 to 7 days before resolving. 
Insulin adjustments are typically too late to catch these trends from raising the average blood 
sugar. The GA_home_computer asks whether Abby has started to have menstrual periods. If 
she has, it recommends increased vigilance for a rise in blood sugar towards the expected end 
of the cycle so that insulin dose can be raised more responsive. It offers Abby the option of 
having GA_PDA provide early alerts for this rise 

After the hospital obtains parental consent, Abby’s full clinical data set is sent by 
GA_hospital_process to the data-base where a large prospective multi-center trial is bang 
conducted for an antihypertensive drug to reduce the incidence of renal disease associated with 
diabetes. After reviewing the data to see if she meets criteria, the GA_hospital_process receives 
an invitation to join the study which it passes on to GA_home computer. After reviewing a few 
lay articles (retrieved by GA_home computer) and a discussion with Abby’s endocrinologist, 
Abby’s parents decline to enroll her because the drug appears to have been insufficiently tested 
with children. Meanwhile those adult patients who are already enrolled and have a GA are 
given an added software component to their GA instances which allows them to report adverse 
events while on this test drug. These adverse events are then directly reported to the drug 
manufacturer, the FDA and the patient's clinician and clinical researchers. 
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Part Il 


Objectives 


Our work includes four major components: (1) design of the Guardian Angel! architecture, (2) 
selection, implementation, and integration of the components of GA that are to be used in our 
experiments and that will form reference implementations for future use and dissemination, 
(3) final selection of the medical domains in which we will conduct our experiments, selection 
of specific sites, patient groups, and goals for the tests, and knowledge engineering of the 
medical content of the GA tools specialized to the selected domains, and (4) conduct of limited 
experimental tests of the system to allow us to assess the validity of our designs. The first three 
of these activities will take place concurrently, although we describe them separately below. 


Architecture 


We are defining GA initial reference architecture by developing an ontology of the entities, 
interactions, and information involved in GA activities, as elaborated below. 

We will complete and refine the domain model to describe, using a taxonomic language, 
all the potentially significant entities, their relationships, and their possible interactions, as in 
the DSSA methodology. 

We will identify the types of software, hardware, and communications systems used in the 
entities with which the GA is to interact. 

We will complete and refine the functional model to describe, using a taxonomic language, 
the inputs, outputs, physical or mental states, and operations or functions of the GA and other 
entities in the domain. Similarly, we will identify and describe all the specializations of these 
operations for different specific classes of entities in the domain model. 

We will formulate a list of all the types of questions one might pose to the general GA 
system, and all the types of questions it might pose to other entities, according to the type of the 
entities. We will formulate similar lists for the additional questions specific to the medical 
foci applications (diabetes, hypertension, anticoagulation, etc.). 

We will prepare or obtain a taxonomic description of medical concepts and relations 
relevant to the foci applications, making use where possible of existing resources such as the 
UMLS[UMLS91], and GALEN[GALE 93] systems. 


Reference Implementation 


We are identifying the representation methodology and taxonomic language for use in the GA 
prototype, and implement methods for translating between the chosen representation system and 
KIF or other representation standards. 

We will identify commercial platforms and applications for the various routine parts of the 
prototype, i.e., communication, database, scheduling software, etc., making use where possible 
of systems already exploited by the other entities in the GA’s environment. 

We will identify initial hardware platforms for both a mobile GA (the GA_PDA of the 
extended scenario) and a fixed GA (the GA_home_computer of the scenario). 

We will identify initial database systems for use in making the system persistent and 
reliable, such as the THOR system[Lisk90] for stable repositories under development by 
Barbara Liskov at MIT. 

We will identify the initial clinical information systems with which the prototype GA will 
interact. 

We will develop an initial backup strategy and implementation to assure continued 
integrity of GA’s data. 

We will build prototypes of the various components of GA, including prototypes of the user 
interfaces presented to both the patient and health care providers. 

We will integrate the components of GA to assure that it functions as a coherent whole. 

We expect that many parts of component implementation, adaptation and integration will be 
recurrent steps, as we learn from experience with earlier iterations. Therefore, we plan to build 
fully-integrated, complete systems as early as practicable, to give us adequate time to perform 
several iterations. 
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Experimental Domains 


We will make a final selection of the specific two medical conditions for which we will test the 
GA approach. Along with these choices, we will also need to identify the particular institutions 
and individual care providers who will cooperate with us in the planned experiments and the 
particular group of patients who we intend to use as experimental subjects. These choices will 
also constrain us to use and support the database and data collection tools at the target 
institutions. 

We will identify protocol-based studies of care for selected medical foci [Fiel92]. With these 
in hand, we will encode these protocols in formal procedures for use by the GA, and use these 
procedures to guide the development of the knowledge base for selected medical foci. 

We will delimit, for each of the two medical domains, the exact bounds of what we plan to 
implement and test. This will involve determining all of the information that will be acquired 
and stored about each patient and the set of patient characteristics that the GA will try to 
influence. 

We will select, implement, and integrate tools that will generate prototype modules. Where 
possible, we will attempt to make use of existing systems for automatic specialization of 
procedures to available knowledge, such as the system developed for automated construction of 
specialized scheduling algorithms developed by Doug Smith at Kestrel Institute for ARPA 
[Smit92]. 

Using these tools, we will implement prototype GA patient management systems for two 
selected medical foci. These prototype systems will provide the basic persistent personal 
medical history, therapy management, explanation, scheduling, and alerting functions. 

We will identify and get rights to use domain-specific material for patient education and 
design and develop connections between the general material and patient-specific information. 

We will integrate the implementation of these prototypes with one or more institutional 
information systems to demonstrate the feasibility of patient-centered medical records. 


Experimental Testing 


We intend to determine experimentally whether the ideas we propose can be successfully 
reduced to practice and whether, when used, they lead to the improvements in health care that 
we anticipate. Because of the severe ethical and legal responsibility that we undertake in the 
conduct of experiments on human subjects, we will work carefully with our collaborators and 
with the Institutional Review Boards of our own and cooperating institutions to define 
experimental protocols that will be based on properly informed consent of all participant 
subjects and that will assure safety during the experiments. Experimentation on human 
subjects with a newly-developed set of ideas and techniques is always a slow process if done 
carefully; therefore, we expect to achieve only limited experimental tests of Guardian Angel 
during the three-year exploration and development project proposed here. If the studies we 
propose here are successful, then we will plan more elaborate trials subsequently. 

We will first try out GA in our selected medical domains by simulating patient use, with 
experimenters acting as surrogate patients. We will use realistic scenarios collected from 
actual patient experience. 

We will then try out GA prototypes with actual volunteer patients, but only under supervised 
settings. This will be during visits to the doctor’s office and in the presence of experimenters, 
and will be intended to test the usability of the system, not its effectiveness. 

If these early studies are encouraging and we have assured the safety of subjects, we will 
conduct some limited trials (see below). 

We plan to evaluate the experiments, and to use their results to: 

(1) Continue evolution of the knowledge base for the selected applications. 

(2) Revise the architecture and implementation based on trial results 

If the limited trials continue to be positive, then we will plan a more substantial evaluation 
based on the anticipated capabilities of the system and its possible extensions. 

We will also plan and conduct technology transfer activities to assure dissemination of the 
architecture and implementation. 
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Technical Rationale 


Current health information systems are built for the convenience of health care providers and 
focus on orderly record keeping for an individual health care setting. This orientation leads to 
two classes of severe problems, which we plan to address through the proposed research: 
alienation of the patient from participation in decision-making concerning his or her own 
health care, and inability of health records to integrate information over the lifetime of the 
patient. Furthermore, many interesting opportunities are missed that would apply new 
technologies to improve decision making and to reduce the incidence of errors in carrying out 
the decisions made. 


Roots of the Problems 


a. Health information for patients. 


Although medical care is obviously given to the patient, exists for the benefit of the patient, and 
must (legally and ethically) ultimately be under the control of the patient, most patients do not 
have a thorough understanding of their health status, do not appreciate their alternative 
diagnostic or therapeutic options, and do not fully understand most of the decisions taken in 
their behalf by doctors, nurses and other health care practitioners. Even medical doctors, when 
they have themselves become patients, have complained of the anonymous treatment they 
receive. Patients without medical training express their disillusionment by exhibiting “poor 
compliance,” and by avoiding clinics until they have obvious major symptoms such as pain or 
visible alterations of anatomy or physiology. The common practice among geriatric patients of 
sharing each other’s prescriptions, the popularity of “alternative medicine” and its unproven 
interventions, and anger at health care providers and researchers may all be seen (at least in 
part) as a lack of understanding and a lack of trust by patients in their providers. 

Traditionally, responsibility fell on the doctor’s shoulders to explain to the patient the 
meaning of symptoms and tests, the possible further diagnostic and therapeutic interventions 
being considered, the known and the unknowable in reaching decisions, and the likely 
outcomes of current plans. As medical practice has become more capable and more complex, it 
has become more and more difficult to explain all this to the average patient. In addition, the 
rapidly increasing pace of medical care means that there is no leisure time for the doctor to 
provide lengthy explanations and to make sure that the patient actually understands. Instead, 
patients are provided brochures and videotapes (for the more common ailments) that describe in 
some generic way the disease they have been diagnosed as having or the treatment that has 
been selected for them. In the absence of such specially-prepared patient education material, the 
patient can at best turn only to package inserts in their medication or to general texts on health 
care, ranging from the Merck Manual to the latest New Age writings. But these static 
information sources (even if accurate) do not help to understand just why this diagnosis 
explains the particular constellation of symptoms worrying this particular patient, or what 
effect the therapy will have on the specific plans or concerns of this individual. No wonder that 
patients turn to friends and neighbors for interpretation and advice. 

We believe that health information systems should be designed and built specifically to 
meet the needs of their subjects, the patients. Therefore, support for helping the patient 
understand and participate in all aspects of medical decision making and its consequences 
becomes not merely a desirable peripheral issue in system design but a clear, central focus. 


b. Life-long information. 


A medical colleague once observed that every hospital in the country is absolutely convinced 
that its own specific procedures for collecting and keeping medical records are unique, and that 
no “ready-to-wear” system could possibly suit it. The history of dissemination of computerized 
medical information systems amply reinforces this view. There is still only a handful of 
comprehensive hospital information systems—ones that are concerned more with clinical 
records than administrative and financial ones—installed at civilian hospitals. Even though 
some of these systems have been in service for many years and are well-proven within their 
home institution [McDo90, Pryo83], attempts to propagate them to other hospitals have been 
generally unsuccessful. For example, two commercial vendors have been promoting adoption 
of the HELP system [Warn72] from LDS Hospital in Utah for nearly a decade, but (as of 1993) 
fewer than a dozen other hospitals have adopted it. Even large administratively-oriented 
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systems such as those sold by IBM for two decades typically underwent such major 
customizations during installation that the resulting systems shared little in common. At least 
hospital-wide information systems have provided common facilities across their single 
institution. At most institutions, even that level of integration has not been achieved. There, 
information known to one departmental system is simply unavailable to others, and it is only 
through the traditional paper record that one can integrate a coherent view of a patient’s 
condition. 

When a patient moves or otherwise changes doctors or hospitals, chances are that many of 
his or her medical records become effectively lost. The new primary care provider can re-learn 
the highlights from taking a careful history, but much of the detail of previous care will be lost 
and much that is retained will be at least subtly incomplete or erroneous. In the exceptional 
case where a past test result can lead to a clear solution of a new problem, old records can be 
found and copies forwarded, but this is an exceptional, not a routine process. Analysis of 
current data must therefore surely suffer. It has been known for over a decade, for example, 
that variations of laboratory values within a single patient are more narrowly distributed than 
are population distributions for the same test [Stat76]. Therefore, even small deviations from 
past values can signal something of possible clinical significance, even though the absolute test 
values are not yet abnormal enough to be notable on their own. 

The deficiencies of current record-keeping systems and proposals to develop new national 
standards for the maintenance and interchange of patient data among providers, insurers, etc., 
are well described in the Institute of Medicine’s recent study, The Computer-Based Patient 
Record [1OM92]. Even this modern viewpoint, however, assumes that the primary locus of 
medical data about a patient is with the hospital, clinic or doctor’s office. It then becomes a 
massive problem to integrate all these data when they are needed. The standardization efforts 
now under way should at least make that data integration possible, but as long as the locus of 
health-care information remains with multiple providers the problems of gaining access to it 
all in a timely manner and properly integrating it remain large. 

We propose instead to refocus health-care information systems on the individual. 
Logically, life-long medical information will be collected and maintained within an 
individual’s personal system, thus assuring the completeness and continual availability of his 
or her records whenever they are needed. The patient-specific components of health records in 
possession of health-care providers are then viewed as secondary, for the convenience of the 
provider. The primary information can always be accessed directly from the individual’s 
system. In addition, active processes within the system can augment the record-keeping 
function to provide a pro-active component that represents the patient’s interests. 


Domain Modeling 


Most of the capabilities we seek to provide through GA are novel. Although others have 
certainly thought of the possibility of personal medical advisor programs, means of 
communicating between an at-home device and a hospital support system, and many other parts 
of the GA vision, very few such components have actually been built, and they have never been 
integrated into the sort of system we wish to build. Experience suggests, therefore, that 
flexibility will have to be a key virtue of our work, because our understanding of precise 
requirements will evolve greatly, technology to support our goals will improve dramatically, 
and we will certainly make our share of poor choices in design and implementation. 

We share the methodology of the Domain-Specific Systems Architecture (DSSA) community 
[Huff94] in recognizing the importance of modeling explicitly the domain’s potentially 
significant entities and their possible interactions. The resulting ontology will provide a 
terminology within which the GA reference architecture(s) can be defined, and will give a set 
of shared concepts for researchers to use in studying, describing, and negotiating specific 
requirements. 

Building a suitable domain model is, of course, one of the early steps of the research. 
Nevertheless, we can sketch at least a rough outline of some of the concepts that are certain to 
play an important role in the ontology: 


lour recent work on identifying growth abnormalities in children demonstrates the same 
point. [Haim93] 
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People 


Patient 

Primary Provider 

Other Providers 

Consultants 

Parents or Guardians 
Family (Spouse, children, ...) 
Commander/supervisor and 
subordinates 


Institutions 


Clinic 

Hospital 

Patient Support Group 
Information Service Provider 
Insurer 

Government 
Employer/military unit 


Settings 


Home 

Outpatient visit 

Hospital stay 

Travel away from home 
Battlefield 


Etiologic Entities 


Disease-causing organisms 
Environmental factors 
Accidents 

Deliberate harm 

Idiopathic causes 


Architecture 


The long-term development of GA will require a highly flexible, open architecture that will 
support expansion of the concept and evolution of its implementation. Yet after GA is in actual 


use, such changes must not ever require a “reset. 


Health Information Systems 


Processes 

- Life 

- Natural course of disease 

- Diagnostic and laboratory tests 

- Normal therapeutic activity 

- Routine functioning of an 
institution 

- Monitoring 

- Computation 


Procedures (descriptions that, when 

performed, evolve processes) 

- Institutional Standard Operating 
Procedures 

- Computer programs 


Relations 

- Causal 

- Taxonomic 

- Geographic 

- Legal 

- Familial 

- Organizational 
- Financial 


Data Sources 

- People (observations, reports) 
- Instruments 

- Laboratories 

- Databases 

- Libraries 

- World-Wide Web 
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We cannot, of course, hope to solve the full 


problem of maintaining installed bases, but we plan to exploit, as explained below, the insights 
of the DSSA methodology to develop an open architecture capable of encompassing a wide range 
of long-term technological developments. 

In addition, it is absolutely critical to our ability to build the system that virtually all 
technology components of GA be provided by generic, preferably standards-based facilities. 
These include: 


data repositories and retrieval, perhaps based on the object-oriented data model 


reliable checkpointing and backup 
computer-based patient record 
security and authentication 
network-based communication 


alerting and notification, including pagers, electronic FAX, and email 


interfaces to data-capture instruments 
easy-to-use user interfaces 


formal expressions of guidelines, practice standards, etc. 


hypertext-based bodies of medical information 
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There is no surer guarantee of failure for this project than to take on the task of building, from 
scratch, technology components that can be adequately provided by commercially available 
means. Thus, for example, one could easily get side-tracked into an investigation of the best 
methods for assuring the integrity of life-long records within a small portable computer that 
would implement GA. One can imagine catastrophes that would result in destruction of the 
device itself, loss or theft, temporary unavailability, accidental or deliberate alteration, etc. 
Although it might be an interesting exercise to work out specific architectural ideas that will 
overcome these problems, it is even more sensible to architect a solution that will rely on 
anticipated commercial services that will provide comparable facilities for a broader computing 
market. Then, specific technology choices can be framed in terms of engineering trade-offs. 

To continue our example of long-term integrity, one could choose an infrequent (say 
monthly) backup tape for people with no serious current conditions. At the other extreme, a 
direct cellular call to a system providing guarantees of data integrity may be worthwhile when 
significant events occur in a patient being monitored for possibly life-threatening events. 
Fruitful synergies may also arise in such an architecture. For example, a hospital may choose 
to go into the commercial business of providing data integrity for its patient’s GA systems; in 
that case, communication costs can be reduced and reliability increased if the same telephone 
call can be used both to report time-critical data (part of the data repository and the alerting and 
notification functions) and to assure that it is backed up in case the GA device might 
malfunction (part of the backup function). 

Some of these facilities are already being provided commercially. Others are the focus of 
active current and proposed research on the National Information Infrastructure. A few will 
require at least prototype development by this project, if not otherwise provided. There is enough 
work to do on integrating these facilities and using them to try out the GA concept that we must 
be very careful not to take on more than what is absolutely essential here. 

The figure below shows a schematic sketch of a portion of the overall GA domain and the 
corresponding pathways for communication. 

At the center is the individual, holding what we have called the GA_PDA in the scenario, 
above. The patient is potentially in direct communication with a set of instruments that help 
gather information about him or her. For the diabetes example, these could include a 
glucometer and a scale with a computer interface forming part of a medical BodyNet [Schi94]; 
but other variations might include communication with exercise machines, or with 
temperature, respiration, and cardiac sensors for infants at risk of crib death (SIDS). We 
assume that the home, in the form of a home computer or access to some networked provider, 
provides more permanent record keeping and access to other services and institutions. Other 
connections link the patient with his or her doctor’s office, to provide a pathway for information 
that requires urgent attention, to civic emergency services, and to wide-area network service 
such as the Internet for information and support services. 


INTERNET 


instruments 


MD INSURER, 


Government 
| Agency,... 
[ay HOSPITAL 
mun 
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This diagram is highly schematic as it omits the probable and possible connections between 
all the other people, institutions, and data sources entering into the domain. In principle, any 
of these entities and their associated GA processes (if any) may communicate with any other, 
but we expect the communication to be direct in only a few important cases that may change as 
the technology evolves. 


Special Functionalities 


The DSSA concept [Huff94] is most easily applicable to domains with existing limited systems, 
and provides a methodology for modularizing and generalizing these systems to facilitate 
future reuse of components in constructing new or variant applications in the same domain. In 
the GA domain, however, there is no existing system from which to generalize, so we must 
begin by designing a specific system. Nevertheless, the concerns of the DSSA methodology 
provide an important guide in this task, as the GA concept involves an array of specializations 
and variations of immediate interest. 

It seems unlikely that any single GA device or overall functionality will be appropriate for 
every person, at least for quite a long time. The different physical and medical needs of 
different people call for very different specific functionalities. The scenario of juvenile 
diabetes presented above calls for functionalities and a sensor (glucometer) not necessary in 
the GA_PDA of the average person. While technological progress may eventually permit 
realization of these capabilities in every GA at negligible cost, in the short run we can expect 
the GA provided to a diabetic to provide functionalities extending or refining those present in 
the generic GA. Similar variations of special skills can be expected for GAs appropriate for 
other special subjects, such as hypertensives, stroke victims, and others. More generally, we 
foresee variations of GA functionality across ages as well. For example, attaching the 
GA_PDA in the scenario above to an infant would not be desirable or feasible, but even in the 
short run we expect a very limited GA to be desirable for infants. This might consist of a purely 
passive personal record of allergies, medical conditions, etc., for use by emergency personnel; 
indeed, one can imagine replacing the standard delivery-room identifying bracelet with a 
more permanent bracelet containing the initial personal medical information. As technology 
permits, this minimal functionality might be expanded to include temperature, respiration, and 
cardiac sensors to alert parents to infant distress and the risk of impending crib death. At the 
other end of life, the generic GA_PDA would also not be appropriate to people suffering from 
Alzheimer’s disease or for comatose patients, and specialized designs might provide the 
appropriate functions for them. For example, the GA of an Alzheimer’s patient might monitor 
the intake of medications and provide address and contact information to bystanders if the 
patient becomes lost. 

In view of this wide range of possible functionalities, we plan to focus our design on the GA 
processes appropriate to the generic adult and to the special medical applications selected 
(diabetes, hypertension, anticoagulation, etc.). Designing for this small variation and keeping 
the wider possible variation in mind will help identify the basic functional modules and their 
possible refinements and alternatives. In some cases, the refined versions will be generated 
automatically from the generic versions and the specifics of the requirements for the variation; 
in other cases, the alternative versions will have to be constructed manually as with the generic 
versions. 


Generic Functional Modules 
Examining the list of GA functionalities presented above, we observe the following generic 
functions of the GA. 

« Recording and representing information 

¢ Monitoring processes 

e« Analyzing events and results 

e Interpreting and explaining plans and references 

¢ Adapting and customizing plans and preferences 

e« Checking plans 

« Communicating, translating, providing, and retrieving information 
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Coordinating functionality distributed among GA processes at different sites 
Educating the subject 

Reminding and alerting the subject and others 

Supporting and socializing the subject 

Scheduling 


Each of these functions will be performed by one or more architectural modules. Some 
functions correspond to a single isolable activity, and will be performed by a single module in 
a given GA, with the only variation being variation across GAs due to the differing needs of the 
subjects. For example, the basic module performing sanity checks on plans might well serve 
all GAs without exception; but in the short run, one can expect different specializations 
according to the special medical knowledge required for different subjects. That is, the generic 
sanity checker analyzing the plans for average subjects need not know the details relevant to 
checking plans for diabetic subjects. Such variations because of differing specialized 
knowledge should be especially amenable to automatic construction and refinement. Other 
functions, however, will be performed by a set of related modules specialized to the types of 
information or the entities involved in the function. For example, modules for recording data 
from bodily sensors will be different as a matter of engineering from modules for assessing 
and recording the preferences of the subject, for representing these preferences to other people 
and institutions, and possibly for representing these preferences to the scheduling module. 


Hardware Realizations 

Seeking maximum flexibility in adapting the GA architecture as hardware technology 
develops entails placing no restrictions on just how the memory, computation, or 
communication functions of the GA domain are realized in hardware systems. The diabetes 
scenario presented above envisions a personal GA residing on something like a current PDA, 
the home GA residing on a personal computer, and makes no particular assumptions on the 
residence of the hospital GA process. But fast downloading abilities, the shrinking physical size 
of computational power, and improvement in the resilience of memory might obviate the need 
for a home GA altogether except as a communication terminal, and improvements in cellular 
telephony and wireless connections to the Internet might obviate the need even for that role. 
Our initial architectural designs will accordingly identify hardware realizations that make 
sense currently and in the near future, but the domain model, functional architecture, and 
modularization will not be dependent on the particular hardware choices in force at a particular 
time. 


Information Infrastructures and 1-95 


We anticipate that the current push toward universal network access for all Americans will 
provide vast new opportunities in health care as well as in other areas of commerce and 
industry. We expect that early exploiters of this universal access will build vertical 
applications that serve specific, targeted users with narrow services. Soon, however, many 
users and providers will recognize the great advantages of open systems that promote 
interoperability and the incremental addition of services to existing systems. For users, this 
will lead to convenience of use and consistency of operation. For providers, it means that one 
can concentrate on doing the best job at providing a specific new service without having to build 
a complete application. 

The 1-95 architecture [Tenn93], in whose creation we participated, envisions a layered model 
of services. At bottom are traditional network services and concerns such as reliable 
communications, addressability, and scalability, plus new services such as security, 
authentication and bounded-delay data streams for isochronous data. At the top are application 
level services and connections to a variety of user interfaces. In-between, we foresee a layered 
set of capabilities that provide uniform support for a large variety of transactions. These 
include electronic money (or, in general, ways of being billed for the use of network services), 
methods to support negotiation and binding commitment in transactions, and means to help 
navigate essentially unbounded volumes of data and text. 

We plan to capitalize on future developments of this set of architectural ideas to support GA. 
Ideally, GA will contribute its own set of layered services and will in turn rest on services 
provided in greater generality for many other kinds of transactions. For example, we expect 
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not to have to develop our own standards for encryption and authentication, but only to design 
the application of those methods [Rive78] to the specific needs of patients and providers in health 
care. 


Prototype Applications 


Implementing the wide range of Guardian Angel applications that we anticipate eventually 
building is a task too large for a single research project. Indeed, we intend for the results of 
this project to provide the appropriate architecture and examples that will enable others to build 
the many specific applications. To help us develop and refine the GA concept, we need to choose 
one or two specific medical applications that can represent the larger medical problem and for 
which we can build demonstrable and testable prototypes. For these prototypes, we plan to choose 
medical domains in which the intensity of required care is higher than normal for the general 
population. This is justified by the medical importance of the applications themselves and by 
the fact that we are likely to learn more from experiments in which “much happens” than 
otherwise. 

Our initial choice of prototype application domains is insulin-dependent juvenile diabetes 
and management of chronic hypertension. 


Insulin-Dependent J uvenile Diabetes 


There are approximately twelve million patients in this country with diabetes mellitus, of 
which one million patients had juvenile onset. The cost of the complications due to the 
microvascular and macrovascular disease of patients with diabetes mellitus is well over four 
billion dollars [Huse89]. Therefore, any improvements in efficacy of treatment will have 
significant national impact. After the Diabetes Control and Complications Trial (DCCT) 
[DCCT 93], a recent multi-center trial, it has become clearer that minimizing the average blood 
sugar of patients will lead to major decreases in the incidence (e.g. 50% decrease in retinal 
disease) and severity of diabetic complications. Also, the Department of Health & Human 
Services has identified in Healthy People 2000 [PHS91] several diabetes-related national 
objectives including reducing the incidence of blindness and end-stage renal disease. 
However, as noted in an editorial commentary on the implications of the DCCT in the New 
England J ournal of Medicine [Lask93]: “We now face the considerable task of providing 
patients and practitioners with the support they need to make this therapy generally available. 
The importance of the patient-centered team in achieving the results of the DCCT suggests that 
policies affecting the way care is organized, assessed, and paid for are likely to be as important 
as those affecting benefits, insurance coverage and access to care. “ 

Even current, non-intensive management of pediatric patients with diabetes mellitus is 
intensive and expensive in its use of health care resources. In addition to regular clinic visits, 
each diabetologist (nurse or physician) will field dozens of phone calls per week from patients 
or their families to help adjust insulin dosage (or oral hypoglycemic agents), diet or exercise. 
Despite this investment of clinicians’ time, the interval between calls for a particular patient 
will range from weeks to months, during which time the current therapy may have become 
progressively less well tailored to the patient’s needs. Sub-optimal therapies will tend to 
increase the likelihood of acute complications (eg. ketoacidosis and dehydration or 
hypoglycemia) and the risk of developing progressive chronic complications (because of 
suboptimal glycemic control). To meet the requirement for more stringent glycemic control 
(which has been shown lead to substantial decreases in vascular complications in the DCCT) 
will require greater patient education, increased clinician/patient communication and 
heightened responsiveness to changes in physiology (e.g. during a gastroenteritis) or lifestyle. 

Several attempts have been made in the past ten years to provide patients with diabetes with 
automated assistance in the management of their blood glucose control [Stra85, Bell88, Buys89, 
Chya90, Fuge92]. These systems have not had a significant acceptance beyond their initial 
testing sights or lasting impact upon the care of most individuals with diabetes mellitus for a 
variety of reasons, including: inadequate user interfaces, hospital oriented care, burdensome, 
unreliable or low bandwidth communications protocols. Also, several of these systems suffered 
from a too narrow focus on the specific clinical task [Fuge92] rather than the broader mandate 
of the Guardian Angel project. Nonetheless, we intend to include these components of prior 
systems that have proven to be successful such as the insulin adjustment heuristics. 
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The objectives of the implementation of a Guardian Angel system for Diabetes Mellitus 
include: 


(1) Decreased patient reliance on expensive tertiary care specialists for routine advice 
on home management’ of diabetes mellitus. At the same time, — timely 
communication of relevant clinical data to the diabetologist (nurse or physician) 
will be increased. 


(2) Improved early intervention to correct harmful blood glucose levels, thereby 
reducing the likelihood of hospital admissions or specialist consultations for acute 
complications and potential chronic complications. 


(3) Increased patient autonomy. 


(4) Improved clinical data collection to help conduct outcomes research and suggest 
improved therapeutic interventions. 


The extended scenario, above, also introduces additional considerations that are important in 
this disease domain. 


Chronic Hypertension 


Hypertension affects 20% of the population of the United States. The prevalence of hypertension 
increases with age, with a higher prevalence in men until about age 50 and then a higher 
prevalence in women [NIH93]. The natural history of the disease is that it gradually becomes 
more severe. Over many years it gradually damages the blood vessels, the heart, the kidneys 
and other organs. The heart hypertrophies and eventually fails. The increased pressure 
accelerates atherosclerosis and produces also hemorrhages in end organs and aneurysms in 
large and small blood vessels, affects the retina, the kidneys, the brain, and the supply of blood 
to the legs. The aorta is subject to dissection (tearing), producing rupture and the cutoff of blood 
vessels. There is a strong, predictive correlation between the level of blood pressure and the 
incidence of coronary heart disease, stroke, heart failure and renal disease. 

The presence of hypertension is usually determined by a regular physical exam or other 
screening, since symptoms are unusual in the early stages of the disease. The majority of 
hypertension is essential , meaning that there is no known cause that can be treated. However, 
it is important to rule out possible causes, since secondary hypertension is treated differently 
from primary hypertension and because treatment can be definitive (curative) for some of these 
causes. Since essential hypertension is progressive and incurable, the disease usually needs to 
be treated for the rest of the patient's life. For the borderline hypertensive, the therapy consists 
of diet, exercise, and monitoring. For mild hypertension, drugs such as diuretics, beta- 
blockers, calcium blockers, and angiotensin converting enzyme inhibitors are all appropriate, 
in different subsets of patients. For more severe hypertension there is a wide range of choices 
of single or multiple drug combinations. The large armamentarium is needed because patient 
response varies, both in degree of response to therapies and in prevalence of and tolerance to 
side effects. It is common to try several different therapies in a patient before finding one that 
provides an adequate degree of control for the hypertension without more side effects than the 
patient is willing to tolerate. 

One of the real challenges is that most hypertension therapies have some side effects and the 
patient often feels better untreated than treated. Many of the common side effects of anti- 
hypertensives are fairly nonspecific, such as headaches, fatigue, dizziness, depression, and 
sexual dysfunction, that might not be attributed to the therapy by the patient without appropriate 
questioning. Since there are usually some drawbacks to every therapy, the decision to reject a 
therapy can depend on the attitude of the patient. As the disease progresses, the therapy may 
have to change to maintain an adequate degree of control. The therapy may also need to be 
changed because of end-organ damage, changing sensitivities and allergies. 

Another challenge of hypertension management is tracking the blood pressure. Blood 
pressure can vary considerably and is often higher in the doctor's office than in a different 
setting. It also follows a pattern over the course of a day and increases with stress and other 
factors. Thus, regular monitoring of the blood pressure provides a much better picture of the 
state of the patient's disease than the pressures read in the physician's office [Pick87]. If the 
physician-read blood pressures are the sole source of data, it takes multiple visits to establish the 
diagnosis of hypertension and frequent visits to track the progress of therapy. Appropriate trend 
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analysis of home blood pressure measurements can provide the physician a better measure of 
the hypertension and the effect of the therapy as well as giving the patient more timely feedback 
and encouragement than waiting for the visits to the physician. 

The blood pressure is not the only focus of management in the hypertensive. Life style 
modification is a very important part of the overall therapy, including changing diet (salt, 
calories, and cholesterol reduction), exercise, often weight loss, stress management, and 
smoking cessation. Since the therapies and other management strategies often have more 
impact on the patient's day-to-day life than the disease, keeping the patient convinced of the 
importance of control, encouraged, and informed is a major challenge in assisting the patient. 
Part of the challenge is getting the patient to take ownership of the management process, 
something that takes instruction and the involvement of the patient in determining a patient- 
specific strategy for managing the disease. This can be very time consuming and the 
assistance of the GA system could benefit the patient and take some of the educational burden 
from the physician. As the GA monitors for early complications (often by asking the patient 
about signs and symptoms), it will reinforce the importance of blood pressure control. It also 
will show the patient the success of therapy and life style changes by showing their impact on 
the patient's risk of complications. For example, several of the Framingham risk equations for 
predicting the development of coronary artery disease depend on blood pressure and many of 
the associated life style changes. The GA will graphically demonstrate how his/her risks 
change over time. This feedback of changes in prognosis for a therapy to prevent complications 
in minimally symptomatic patients should be very effective as it will show them the expected 
effect of therapy. 


Managing Hypertension Using a GA 


At different stages in the management process, the GA could serve different functions for the 
patient and for the providers. When hypertension is first suspected or noted on a routine 
examination, the physician will load and activate the hypertension GA in the patient's 
computer. Initially, the GA could assist in the screening and diagnosis process for the 
physician. The GA would collect any additional needed demographic information and 
information about the risk factors for myocardial infarction and stroke. This function may be 
of particular importance because modern trends in health care continually limit the time 
available for patient-physician contact. How complete a history can be taken in an eleven 
minute visit? The patient could also get information about hypertension and the various risk 
factors. If a health care provider (nurse or physician's assistant) is entering blood pressure 
measurements into the office, clinic or hospital system, that information would be transferred 
to the patient's GA computer. If a hypertension workup is appropriate, the GA would gather the 
rest of the history needed by the physician. At this stage of the interaction, the GA could give the 
patient a preview of the implications of risk factors that are apparent from the history and 
initial blood pressure readings along with other information that would help the patient be more 
informed when interacting with the physician. 

When the patient's GA transfers the data to the GA physician's process, the data needed to 
begin the diagnosis will be available to the physician. If the patient already has some of the 
necessary screening tests, those data will be immediately available and some unnecessary 
duplication will be avoided. The GA will also be able to provide data about trends in tests over 
time, for example how the serum creatinine may have changed (reflecting renal disease, both a 
cause and a complication of hypertension). The diagnostic module on the GA physician's 
process can then provide patient-specific source of information about the diagnosis and 
management of hypertension. It could provide suggestions for therapy or a critique of proposed 
therapy in the context of other diseases (co-morbidities) or special circumstances that may be 
affecting the patient [Mill84]. For example, in a patient with a history of depression, a beta- 
blocker would be inappropriate. The information could be provided in the form of a guideline 
or in response to questions, as appropriate to meet the needs of the physician. The GA 
physician's process would also provide access to other information sources, such as references 
to literature on secondary causes of hypertension, the current costs for drugs, availability of 
classes or therapy groups for the patient on diet, quitting smoking, exercise, or living with 
hypertension. It would also provide information about the patient's response to drugs given 
before (about which the current provider may not be aware), as well as allergies or how other 
drugs might interact. Data would also be provided to the patient. For example, most common 
over the counter remedies for upper respiratory infections warn the patient to avoid them without 
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consulting their physicians. In the case, the GA could provide a selection of minimally 
problematic drugs and then monitor the patient's blood pressure response to those drugs and 
note the results for future reference. 

Once the patient has been diagnosed with hypertension and the physician has determined 
an appropriate course of action, the patient's GA will assist by helping the patient take 
ownership of the plan. To successfully combat hypertension requires a long-term commitment 
and consistency, so the patient must understand the situation, understand the implications in 
managing the disease, and be committed to the management plan. The GA will provides an 
effective tool to take the patient through these steps. It will answer questions about the patient's 
risk of heart attack or stroke or the other consequences of hypertension and frame this 
information in a variety of ways that might help the patient understand. It will help the patient 
understand the additional risk incurred from smoking, diet, obesity, stress, and so forth. The 
GA will also help the patient personalize the management plan so that the goals are ones the 
patient is committed to achieve. This management plan will incorporate the GA as a monitor 
and guide by including a commitment to consult with the GA on a regular schedule. 

Once the patient and physician have established a management plan, the GA will help the 
patient follow the plan and monitor the progress. For most patients, who are able to check their 
blood pressure with the home pressure cuffs now available, the GA will track the pressure 
against the expectations for therapy effect and use the data to provide correction and 
reinforcement for the patient. The GA will also monitor other aspects of the plan including 
drug compliance, weight, and lifestyle changes. The degree of monitoring of side-effects and 
lifestyle changes such as diet and exercise will depend on the needs and desires of the patient. 
It could vary from simply making information available to having the patient fill out a 
progress report each session. Importantly, the GA will be able to ask about most of the potential 
side effects of the drugs. From our interviews with hypertension patients it is clear that some 
like to know what the possible side effects are while others would prefer having them monitored 
in case they happen. Indeed, there are preliminary data that suggesting to a patient that certain 
side effects might occur, eg., insomnia or erectile dysfunction on beta-blockers, will markedly 
increase the frequency of those side effects. The GA will accommodate individual preferences 
for information compared to monitoring. The GA will help the patient evolve the plan to meet 
changing needs, such as revising an exercise program to accommodate a change in schedule. 
By occasionally linking the GA to the physician's GA module via modem, the GA will schedule 
follow-up with the physician. Since the GA has the monitoring data, it can determine the 
urgency of the visit. Indeed, if expectations have been met and there are no indications of side 
effects, it may be appropriate just to add the data to the physician's data base and delay the visit, 
unless of course it is time for some regularly scheduled laboratory test (e.g., a potassium or an 
echocardiogram to monitor changes in left ventricular mass) or unless some other problem 
requiring the physicians attention has developed. 

The GA will act as a resource to answer the patient's questions as they arise. The GA would 
assist in this process by keeping track of what information the patient has seen and by 
suggesting related information, information consistent with the patients interests and 
knowledge. Many kinds of information about the disease, the therapies, lifestyle changes, and 
so forth will be available with a simple hypertext interface. The GA will be able to access 
functionality on other computers to supplement that available locally. For example, if the 
patient has agreed to a certain kind of diet, transparent access through modem to another server 
may provide a list of restaurants and dishes that would meet those requirements when the 
patient wants to go out for a meal. Such network access will also allow the patient to participate 
in support groups or mailing lists to exchange views, keep informed, and be encouraged by 
people in similar situations. Often the best way to stay on track in managing a lifestyle 
change is to interact with someone else fighting a similar battle and be accountable to each 
other. Access to network mailing lists or information servers will also make available timely 
responses to articles that appear in the press or television about some aspect of hypertension. 


Chronic Anticoagulation 


Anticoagulants are drugs which limit the ability of blood to clot and are used commonly in the 
treatment of cardiovascular disorders and therapies that subject the patient to a risk of 
thromboembolism. Classic indications have been prior embolic stroke, the insertion of 
prosthetic heart valves, the presence of acute and recurrent venous thrombosis (phlebitis) and 
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pulmonary emboli, the presence of cardiomyopathy (disease of the heart muscle) which limits 
the strength of cardiac contraction, and the presence of certain cardiac arrhythmias, e.g., atrial 
fibrillation. Recent studies have underscored the need for anticoagulation and careful 
monitoring of the patient's response to these drugs (as typically measured by the prothrombin 
time, a measure of how long it takes the blood to clot under controlled circumstances in the 
laboratory). Patients responses to these drugs (most commonly warfarin) are quite variable 
from patient to patient and from moment to moment in a given patient. Recent improvements 
and corrections in laboratory science have minimized some of the non-biological variation, but 
the situation is sufficient unstable that laboratory studies of a patient's response a measured at 
least monthly and often far more often. If anticoagulation is inadequate, the patient is at risk 
for thrombo-emboli; if it is excessive, the patient is at risk for hemorrhage. The toxic-therapeutic 
ratio is quite low and variable. 

Almost irrespective of the purpose of the anticoagulant therapy, the management is the 
same. A therapeutic goal (a target range of the laboratory value, the INR (international 
normalized ratio) is established as well as action levels outside that range, with actions such as 
repeating the study, changing the dose, given an antidote or another anticoagulant (eg., 
heparin as a supplement), and hospitalizing the patient. Because of the frequency of problems 
and changes in therapy, it is critical that the patient be a partner in the therapeutic process, 
understand the implications of laboratory values, and understand the signs and symptoms of 
the complications of excessive or inadequate therapy. A very large set of other drugs also 
interact with anticoagulants, causing the risk of bleeding or of thromboembolism to increase, 
sometimes without changing the prothrombin time. The patient must be educated about these 
effects, because an intercurrent physician treating an acute problem may inadvertently 
prescribe a drug that interferes with safe and adequate anticoagulation. The patient must also 
be taught about a wide variety of over the counter drugs that can cause bleeding or inadequate 
anticoagulation. 

Given the frequency of problems with anticoagulant therapy and the importance of this 
lifesaving therapy that is often continued lifelong, we believe that a GA for anticoagulation will 
be an important benefit. It should make this therapy safer and more effective, while keeping the 
patient involved and responsible. There are even portable instruments (one made by Dupont, the 
primary manufacturer of warfarin (Coumadin)) with the patient can purchase to measure the 
prothrombin time at home at about one dollar per test. The output is digital and should be able to 
be directly interfaced to the patient's GA. The frequency of testing and changes in therapy and 
the need to monitor for side effects and drug interactions make this domain a prime candidate 
for GA software agents. The frequency of changes in therapy (especially when therapy is first 
started or when it must be temporarily discontinued, eg., for surgery or even visiting a dentist) 
means that we should be able to do substantial testing of this application in a relatively short 
time. This domain is also interesting because the GA will not be focused on a single disease but 
rather on the effects an the management of a common therapeutic agent. It may be prototypical 
of a large set of software agents that might be prescribed for a patient (loaded into his/her 
computer) when a drug is prescribed, to teach the patient about the drug and its use and 
necessary precautions. 

We shall develop and anticoagulant GA which will monitor the effects of the drug, trying to 
keep the patient's response (INR) within the prescribed target range. It will educate the patient, 
help the patient understand how drug dose should change with laboratory response, watch for 
complication and try to prevent or at least compensate for drug interactions. Because the 
protime might be more frequently and closely monitored at home than can now be done by 
visiting a laboratory and getting a blood sample obtained by venipuncture, control should be 
tighter and safer. When scheduled intercurrent events are planned (eg., a visit to the dentist or 
a sigmoidoscopy), the GA will help the patient and the physician minimize the window during 
which the patient is relatively unprotected from thrombo-embolic events. The GA will keep the 
physician informed about the patient's response, progress, and complications, and its 
recommendations to the patient will (can) be monitored or adjusted by the prescribing 
physicians. Some busy physicians even now delegate anticoagulation management to 
assistants or nurses, so this pattern of care is already partially commonplace. 
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Other Domains 


The domains described above are only three of a number of medical problems that could be 
fruitfully attacked by prototype GA implementations. We have mentioned angina, chronic 
renal disease, and pulmonary disease (COPD) as other possibilities. If time permits, we may 
undertake additional prototype implementations in these domains, to further study the 
adaptability of the GA concept, the GA reference architecture we will build, and the reusability 
of components built for the initial the domains. In selecting the three domains we have tried to 
select problems and expose different opportunities for GA functions, e.g., managing drugs, 
monitoring physiology, educating patients, watching for early complications, looking for 
interactions with other diseases or drugs. 

Angina, for example, is a domain in which a GA has the potential to reduce the incidence of 
myocardial infarction and death. Since the majority of patients experiencing a myocardial 
infarction describe a change in their anginal pattern within a couple months prior, the 
detection of such changes in a more reliable way than relying on patient observation and 
concern, offers the opportunity to intervene in many cases that would otherwise proceed to 
infarction. 


Implementation 


Designing our initial implementation strategy is one of the tasks in our research. 
Nevertheless, we can outline some of the approaches we plan to pursue in implementing the 
capabilities we propose to build. We focus first on initial hardware platforms, and then on the 
software environment. 

We assume that, in the short term, lightweight devices with relatively limited 
computational power will be used routinely by patients in our experimental studies. This will 
mean either a “personal digital assistant” class machine such as the Apple Newton or a very 
small, lightweight portable computer such as an HP “palmtop” or a larger machine such as a 
Duo. During the term of this project, such machines are not likely to have either the 
computational power or the storage capacity to hold all the material that GA will require. 
Therefore we posit the presence of a home computer (a PC-class machine or workstation) with a 
large disk drive, CD-ROM, keyboard, and large color video display. Communication paths 
between the PDA, home computer, and other aspects of the network will have to be always 
available, reliable, high-bandwidth, and convenient to use. For close proximity, infrared 
devices appear to be appropriate. For more distant connections from PDA to other machines, the 
current technology of choice is probably cellular telephone, though this may change as satellite 
based direct communication channels come on line. We assume that, at least by the time we 
are ready to conduct field trials, the home computer will be attached to the Internet via high- 
speed telephone switches or set-top cable converter boxes, and therefore the communication 
facilities of the Internet will be available in the home. Therefore, we plan to use Internet 
services as the basis for communication with the doctor’s office, hospitals, insurers, third-party 
payers, government organizations, other patients and support groups, etc. If, contrary to our 
expectations, high-speed networked connectivity to the home is not available, we would have to 
turn to existing alternatives such as high-speed modems or leased lines to conduct our studies. 

Our collaborative team brings a very valuable suite of software tools to our project. 
Gensym’s G2 and GDA (G2 Diagnostic Assistant) software provides an excellent environment 
for prototyping GA components and for developing monitoring and tracking modules. It has 
been used in process-control applications to construct reliable agents with long-term plans and 
agendas, and should allow us to create multiple independent software agents that collectively 
constitute the reasoning part of GA for a specific individual. G2 and Gensym also have 
considerable use and experience in interfacing to a variety of different information systems, 
and provide tools that make creation of data interfaces relatively simple Because we will need 
to interface with a variety of record-keeping systems in doctors’ offices, hospitals and other 
institutions, this will be a critical contribution. In addition, the temporal aspects of this 
software will provide us models for forms of knowledge representation we expect to be 
important, but which are not yet fully supported in KIF [Gene92] and KQML [Baal94]. 

IBM’s Applications Solutions Institute has developed, in their collaboration with Kaiser 
Colorado, a set of tools for compiling workflow specifications into program code that 
implements those workflows. These capabilities will be very important to the components of the 
GA architecture that run at institutions away from the patient, where the needs and concerns of 
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many patients are intertwined and need to be simultaneously managed. IBM is currently 
using these tools to develop software for more conventional HMO operations, and we plan to 
investigate how they are applicable to the management of the far more patient-controlled data 
streams that will result from use of GA. IBM has also developed a set of tools to manage 
taxonomies of medical terminology, and is currently using these to define controlled 
vocabularies and medical relations for use in their HMO record keeping systems. We believe 
that a coherent set of terminology, though not absolutely essential, makes record-keeping and 
interpretation far easier and more effective. We plan to use the UMLS as our base vocabulary, 
where its coverage is sufficient, and to use the IBM tools and vocabularies as much as possible 
to supplement UMLS with terminology needed to cover descriptions of patient data. 

The MIT Laboratory for Computer Science plans to pursue an aggressive research and 
development strategy to make use of the Word-Wide Web (W3) [Bern92] architecture as a 
foundation for our planned I-95 extensions. In concert with this, we plan to use W3 extensively 
as a foundation for accessing general medical information, patient support groups, the 
technical literature, and patient-specific records. If suitably augmented with privacy features, 
existing tools that provide HTML access to various forms of databases and widely-available 
front-end tools such as NCSA Mosaic can then provide high-quality interface components that 
require little effort on our part to develop, yet provide excellent functionality and uniform 
interface conventions for our users. 

Not every implementation component of GA can be obtained “off the shelf,” of course, and 
we certainly expect to have to build various software modules and code to tie together and 
integrate others. As we have mentioned, these implementation commitments are subject to re 
evaluation before the project commences as technologies change. They are, however, 
representative of our commitment to leverage as much as possible from our own previous work 
and the outstanding work of others. 

One of our initial concerns will be the form of the data model. In the GA environment the 
data needs to be useful for the life of the patient and by modules yet to be conceived. Thus, we 
can not assume that because no current modules use certain data, that it will not be needed 
later. Furthermore, the data comes from multiple contexts and sources, which may be pertinent 
to its appropriate use. Unlike a hospital based system, there is no underlying assumption that 
all data has been collected or filtered by appropriate clinical personnel. Thus, it will be 
necessary to store contextual information along with the data. For example, in the diabetes 
example, when a glucose level is recorded, the datum must include that it was done by the 
patient at home, the type of glucometer, and that it was recorded by direct connection (as opposed 
to typed in). Other information, such as the food and exercise state of the patient, are also 
pertinent but would be available as data items themselves. The actual implementation of such a 
data scheme does not have to be burdensome, since context information can be carried over sets 
of data. The starting point for designing the data model is the domain model. The 
relationships among the entities in the domain determine the classes of information that must 
be available in the data. 

There are several different kinds of data that need to be a part of the GA system, with 
different implications for storage and access. The most obvious type is the disease findings, 
such as the glucometer findings or exercise logs. These constitute the basic track of the disease. 
In contrast, the GA also needs to keep track of the educational materials the patient has 
reviewed in order to offer new materials when the patient has questions and to have a general 
characterization of the patient’s disease understanding. The requirements for data security are 
very different for these two kinds of information. The loss of the raw disease data would 
represent a loss of part of the basic patient disease record. The loss of the patient education trace 
is little more than an inconvenience. Thus, the data model needs to capture the varying needs 
for reliability, security, and access for different kinds of data. 


Comparison with Ongoing Research 


To our knowledge, this proposal represents a novel departure from both our own and our 
colleagues’ ongoing work in the development of medical information systems. The history of 
medical informatics begins in the 1960’s with the computerization of the collection, storage and 
retrieval of clinically-relevant data, initially focusing on data from the clinical laboratories. 
Over the past three decades, this focus has expanded to making possible the comprehensive 
collection and maintenance of clinical data from many other sources, including radiology, 


Guardian Angel—Patient-Centered Health Information Systems 24 


pathology, pharmacy, |CU monitoring equipment, etc. [Ball91]. Hospital information systems 
being introduced today are moving away from the monolithic centralized systems of earlier 
days and now support networked interaction among heterogeneous components, with broad 
conventions and policies governing communication (e.g., HL7 [HL7] as a network 
communication format), queries (e.g., SQL for access to stored data), and interactions with 
other hospital responsibilities (e.g., a policy requiring that billing be performed based only on 
data recorded in the clinical information system). Nevertheless, all such systems are still 
centered on the care-providing institution, not the lifetime experience of the individual patient. 
Current efforts to define a set of standards for communicating information in the patient record 
(e.g., CPRI) are intended to facilitate the exchange of relevant patient information among 
various providers, but integration of this information is still planned to be optional and to 
remain the responsibility of the current provider. No provisions are made for long-term 
patient-centered evaluation of these data or for active processes that can represent the patient’s 
viewpoint and preferences in medical decision making or that can prospectively identify errors 
as defined by the patient. 

Current efforts in medical Al center on a number of different types of tasks: 
(1) Development of model-based reasoning techniques and systems that can accurately reason 
about complex medical domains. Our group, for example, has been developing a program to 
reason about diagnostic and therapy management problems in cases of heart failure, helping 
physicians to manage very ill heart patients. (2) Create methods to learn medical knowledge 
from the growing volume of data available in information systems. Examples here include 
statistical learning methods like CART [Brei84] and C4.5 [Quin93] Bayesian network induction 
methods [Verm90], case-based reasoning [K oto88, J ang93], and various approaches to knowledge- 
base debugging. (3) Develop tools that make the construction and deployment of relatively 
conventional (well-understood) systems easy and inexpensive. See, for example, the hierarchy 
of tools embodied in the Protege project of Musen, et al. [Muse89] (4) Provide integrative 
functions across heterogeneous data sources, with slightly intelligent interfaces in “physician 
workstation” projects [Koha90] . (5) Standardize methods of expression of clinical data (eg., 
CPRI), medical terminology (e.g., UMLS) and isolated chunks of interpretive expertise (e.g., 
Arden Syntax MLM’s [Hrip90]). (6) Codify and help to implement guideline-based care for 
routine problems, based on flowcharts and possibly some exception mechanisms [Fiel92]. 
Although each of these approaches is relevant to aspects of our proposal here, none is addressed 
at our specific task and plan. We hope to make a major contribution to medical informatics 
with the ideas sketched here, as developed through the conduct of the proposed research. 


Performance Evaluation 


Evaluating a new paradigm for health care delivery provides many methodological challenges. 
The evaluation of incremental changes in a system is relatively straightforward, because there 
is a clear null hypothesis—the new system is no different than the old—and either parallel or 
cross-over studies can provide evidence about this hypothesis. Problems normally revolve 
around finding suitable outcome measures (e.g., are improvements in measures of the process 
of health care sufficient, or must we show ultimate benefit in terms of reduced patient mortality 
and morbidity), and designing studies with sufficient power to reject the null hypothesis without 
inordinate expense. 

In our case, evaluation is made more complicated by the fact that both our own ideas on how 
to build GA and the more traditional approaches to providing medical informatics will evolve 
during the course of the project. Because of this expected evolution, it makes less sense to 
perform a single final evaluation of the total system than to combine small, incremental 
evaluation steps with continued research and development. Many of the questions we will be 
asking are not of the form “does method x perform task t better than method y?”, but more “how 
can we accomplish t at all?” The first steps in evaluation are, therefore, less a matter of 
empirical analysis of the performance of existing systems than part of the engineering design 
effort. We expect much of the first two years of our project to be devoted to research and 
development toward the GA goals, and therefore to involve mostly “how can we...” questions. 

The third year of the project will focus on the performance evaluation of the GA. The 
objective of the evaluation is to prove the viability of the idea of patient-centered health 
information systems. Furthermore, we will use this evaluation to prepare the GA system for 
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appropriate clinical trials. In addition to evaluating the performance of GA in specific 
application areas, we are also interested in judging the success of its architectural design in 
making possible the creation of new GA applications in new settings. We do not expect to be 
able to carry out controlled trials of this aspect of the system during a three year study, but we 
are designing all stages of our evaluation to provide feedback on this question when possible. 

There are four levels at which a system such as this needs to be evaluated, from system 
functionality to patient outcome. The following are the hypotheses that need to be tested at each 
of these levels: 


1. The system successfully implements the performance characteristics we have set 
out. That is, it is able to collect and maintain the appropriate data, communicate 
with the other processes, handle the expected tasks for the patient and other users, 
and handle the various possible failure modes of the distributed system. 


2. The system gives good advice. 
3. Thesystem is judged to be useful by the users. 
4. The system improves patient outcome or compliance. 


Because each of these levels of evaluation rests on the previous level and we are testing a 
completely new paradigm in medical assistance, most of our effort will, of necessity, be focused 
on the lower levels of evaluation. However, we will do some evaluation at each level. The 
objective of this evaluation is to determine whether the system merits the expense and time 
required for a full clinical trial. This is a formative evaluation, so we will make 
improvements to the program as we uncover limitations. The following paragraphs discuss 
what we will do to evaluate the program at each of these levels. 

To judge whether the system successfully implements the desired performance 
characteristics, we will design a series of scenarios that test the behavior of the system for all of 
the desired functionality in the two medical domains. The scenarios will include examples of 
all of the desired kinds of communication the system will have to handle. In addition, they 
will include the range of likely failures in these communications. For example, we will test 
whether the system does appropriate alternative notification in case of emergencies when the 
primary destination is unavailable. Because the ultimate intention is to have a system that 
assists patients for their lifetime, we will test that the system state is reliably maintained by 
testing that the system is able to recover from the failure of any single component. We will 
include scenarios that involve the addition of new modules to the system to test its extensibility. 
When it is clear that the desired functionality is well in hand, we will commence with the 
second level of evaluation. For both of the medical domains, we need to test the domain 
knowledge of the GA. For this we will use a combination of designed scenarios and, later, 
cases constructed from data gathered from patient use of the GA. We will use a set of scenarios 
that covers as wide a spectrum of decision situations as possible to give the domain knowledge a 
thorough test. We will collect the analysis, actions, and advice of the system at each decision 
point in the scenarios. These decisions will be given to domain experts to judge. The experts 
will be asked to judge each decision as good, acceptable, or wrong. The decisions judged wrong 
will be reviewed to determine the basis for the judgment and the appropriate way to deal with the 
problem. Once the program has achieved a level of domain performance in which the mistakes 
are infrequent, the system will be advanced to the third level of evaluation. 

The object of the third level of evaluation is to determine whether the system is perceived by 
the patient and physician to be useful. This is a necessary hurdle for the system to clear 
because the system depends on acceptance, especially by the patient, for it to be used and to serve 
its function. To conduct this evaluation we will select a small number of patients (probably 5) 
who have each target disease and equip each with the system for three months, under 
supervision of a physician who will have the corresponding part of the system for the physician. 
For the hypertension domain it may be necessary to give the GA to the patient for a longer 
period of time, perhaps up to six months, because interactions with the system will be less 
frequent than with diabetes. We will enlist patients at different stages of their diseases in 
order to get a better idea of the strengths and weaknesses of the system. The system will be 
instrumented to collect comments from the patient and physician, as well as the complete record 
of the use of the system. We will design this test to minimize the potential risk to the patient in 
collaboration with our Institutional Review Board (IRB). For example, all advice given to the 
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patient will also be given to the physician. Any advice that involves a change in therapy (such 
as a response to side-effects) will require the prior approval of the physician. These safety 
features will have to be balanced against the responsiveness of the system. After the first 
session of use, at an intermediate point, and at the end of the study period, we will ask the 
patient and physician to fill out questionnaires about the strengths and weaknesses of the GA. 
This field trial will also be a vehicle for testing whether the performance characteristics of the 
system hold up in practice. In particular, it will give us a good test of the reliability of the input 
data and the willingness of the patients to comply with the GA over an extended period of time. 

Using the data from this field test of the system, we will analyze the record, looking for 
instances in which actions were taken as a result of the information provided by the GA 
system. These will be classified as to whether they increased or decreased the need for 
physician intervention and hastened or delayed optimal therapy. The resulting balance sheet 
will be used as a rough measure of the amount of improvement that could be expected from the 
GA system in each domain. The expectation is that this will provide enough data to do the 
power analysis for a full clinical evaluation. Such an evaluation will be planned, but it will 
not be carried out during the proposed project period. 


Conclusion 


We expect to publish reports that delineate the domain of active intelligent patient-centered 
health information systems, architectural documents specifying the reference architecture of 
Guardian Angel and its interfaces, a succession of prototype software implementations of GA 
and its applications, and research reports describing the above and evaluations conducted to 
assess the validity of our assumptions and (ultimately) the efficacy of the underlying concepts. 
We expect the example applications to measurably improve medical care, and we will also 
make those applications available to interested adopters. Because we plan to make available 
both a reference architecture and a set of reference implementations, potential adopters can 
choose whether to build new implementations based on the architecture or to adopt our reference 
implementations. To the extent possible, we would like to make the reference implementations 
available to others at little or no cost, but because they are likely to include components that are 
commercially developed, this may not be possible. We can guarantee for-fee availability of the 
reference implementation. 


Schedule 
We propose a three-year project, incorporating the following tasks: 


Year one: 


Define GA initial reference architecture 


Select initial implementation strategy: specific medical, institutional and hardware 
environments. 


Identify protocol-based studies of care for selected medical foci. 
Begin development of knowledge base for selected medical foci. 
Begin selection or implementation of tools that will generate prototype 


Year two: 


Complete implementation of authoring support system 

Implement prototype GA patient management systems for two selected medical foci. 
Integrate implementation with institutional information system(s) 

Simulate use with experimenters acting as surrogate patients 

Plan evaluation based on anticipated capabilities 
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Year three: 


Continue evolution of the knowledge base for the selected applications 
Conduct limited field trial(s) and perform their evaluation 
Revise the architecture and implementation based on trial results 


Plan and conduct technology transfer activities to assure dissemination 
architecture and implementation 


of 
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Part Ill 


Project Partners 


The project will be done as a collaboration among the Clinical Decision Making Group at the 
MIT Laboratory for Computer Science and researchers at two Boston-area hospitals, two 
companies, a large HMO, and a part of the Veterans Administration. 

IBM Research has agreed to collaborate with us in basic research towards building health 
care solutions and plans to contribute to this program some appropriate existing and under 
developed software tools under fee-waived license agreement. |BM’s Dr. I fay Chang, who heads 
the Applications Solutions Institute (ASI) within the T. J. Watson Research Laboratory, is 
currently leading a very large-scale effort to develop a modern clinic-based information 
system for the Kaiser Colorado health plan. As part of that activity, ASI has developed a 
number of tools that we expect will be useful for prototyping and that will probably serve as 
reference implementations for portions of our reference architecture. These include tools for 
application definition and information and workflow modeling, for defining and maintaining 
a medical lexicon, and for building clinician’s workstations from abstract specifications. Asa 
commercial company, it is reasonable to expect that IBM will be interested in turning these 
tools (or their offspring) into commercial products. For this research program, Dr. Chang has 
agreed to work with us to develop mechanisms that would assure potential adopters of our 
system the ability to license, at a reasonable cost, components of |BM technology that we have 
incorporated in our reference implementations. 

Gensym, Inc., is a small software company in Cambridge, tracing its roots to earlier MIT 
projects about 15 years ago, and is the most successful commercial vendor of tools for 
intelligent process control. Their graphically-oriented expert system shell, G2, has been used to 
build hundreds of systems for keeping track of evolving manufacturing processes, and they 
have built various tools to augment G2 for diagnostic reasoning and for interface to 
heterogeneous databases (two examples relevant to our proposal). Lowell Hawkinson, CEO of 
Gensym, has agreed to grant to this project six licenses to Gensym’s commercial tools G2, GDA 
and associated support tools, and will dedicate one staff member (if funded via this proposal) to 
help develop the architecture and reference implementation for long-term GA agents. 
Gensym’s products are available for commercial purchase by any interested user. 

One of the concerns of all the involved parties is the question of liability for the medical 
knowledge contained in our implementations, and its potential impact on individual patients. 
We plan to maintain a strict separation between the software tools that we develop or adopt and 
the medical content that is encoded with those tools. This is not only good engineering practice, 
but will also alleviate concerns about legal liability on the part of the tool providers. 

Our other partners in this project, Tufts/New England Medical Center, The Children’s 
Hospital, The Boston Development Center of the VA, and Kaiser Colorado have no proprietary 
claims to any existing programs or to the software that we develop. They will have rights to the 
formalization of medical expertise contained in the system, to the extent of their contributions to 
it. 

Although we have not at this stage made final decisions about the exact nature of the 
collaborative relationship, everyone involved in the project agrees to the following principles: 
(1) The GA architecture and ideas should not be encumbered by proprietary claims, except 
perhaps those assigned to a consortium that is committed to public dissemination. (2) Products 
contributed by participating commercial vendors shall be freely available for use during the 
conduct of this project, but without ceding commercial rights. (3) Vendors commit to making 
available, either as products or under special licensing arrangements, any components of 
reference implementations produced. 

To date, there are no proprietary claims by any external party on the ideas of this project. 
The MIT researchers named in this proposal have full control over all intellectual property 
rights. Our intent is to maintain unencumbered all such rights to the architecture and 
technical specifications of Guardian Angel, so that if the project is successful we will have the 
greatest likelihood of being able to encourage its widespread use. 

By the end of this project, we anticipate having created a domain-specific software 
architecture for GA agents and their supporting environments. Further, we plan to have 
defined a reference architecture appropriate to contemporary computational and communication 
technologies. In addition, we plan to have produced one or more reference implementations 
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consistent with this architecture, both to support our experimental applications and to give 
potential adopters an easy place to “get on board”. (This is, we believe, one of the main positive 
lessons from the successful X-consortium run from our laboratory during the past decade.) The 
cost of building such reference implementations from scratch would be prohibitive, and we have 
organized a collaborative team intended to make this process much more efficient. 


Previous Accomplishments 


This proposal brings together a moderately large, heterogeneous group of computer science 
researchers, physicians, and software developers to explore a new paradigm of using computing 
to improve health care. The major participants are: 
Computer scientists at MIT: Drs. Peter Szolovits, William J. Long and J on Doyle 
Collaborating physicians in Boston: Stephen G. Pauker, M.D., Mark Eckman, M.D., 
and J ohn Wong, M.D., of New England Medical Center, and Isaac Kohane, M.D., 
Ph.D., of The Children’s Hospital 
Michael L. Meistrell, M.D., Chief of Medical Informatics at the VA’s Boston 
Development Center 
Gensym, Inc.: Lowell Hawkinson, CEO, Steven Fraleigh, and a software engineer 
IBM Corporation, specifically the Applications Solutions Institute of the T. J. Watson 
Research Laboratory, directed by Dr. I fay Chang 
Kaiser Permanente of Colorado, currently implementing a clinical information 
system with the |BM group. 
We sketch the background of each of these groups below. 


MIT Laboratory for Computer Science 


Attempts to build intelligence into computer programs operating in health information systems 
began with early programs in the 1960’s based on flowcharting and simple statistical methods. 
G. Anthony Gorry, the founder of our group at MIT, for example, explored sequential Bayesian 
methods for optimizing diagnostic reasoning. Based on difficulties of these early methods, 
researchers, including us, in the 1970's turned to simulating the cognitive processes of expert 
human clinicians as a basis for building expert advisory systems. Many of these early “Al in 
Medicine” (AIM) systems used clinical associations and rules, and encountered grave 
difficulties in clinical problems involving interactions among multiple disorders, partially- 
treated diseases, and the need to monitor ongoing treatment. As a result, we led a move toward 
“deeper,” model-based medical reasoning systems starting in the late 1970's, using inferences 
about pathophysiological models at various levels of detail to deal with unanticipated situations. 
Our research has broadened to include problems of explanation generation, to use more complex 
probabilistic and heuristic inference models, to learn from experience, to deal with time 
dependencies systematically, and to model and use preferences in decision-making. We have 
also contributed to medical knowledge representation, KR in general, truth-maintenance, 
qualitative reasoning, and modeling repetitive decision-making. We illustrate some of these 
developments by a brief historical recap of our more significant projects. 

Gorry introduced the sequential Bayesian diagnostic method in 1967 [Gorr68]. It uses 
information theory to select “most informative” questions, and decision analysis to decide 
which costly tests and treatments are worth doing. Applications in congenital heart disease, 
acute renal failure, and others, illustrated the strengths and limitations of the simple 
independence assumptions embedded in the probabilistic model. Nevertheless, the technique 
proved quite valuable in such medical specialties as managing the diagnosis and treatment of 
Hodgkin’s disease. 

Our first diagnostic program that attempted to model the reasoning processes of clinicians 
was the “Present IIIness Program” (PIP), reported in American J. Med. in 1976 [Pauk76]. It 
adopted a hypothetico-deductive framework for diagnostic reasoning, using strong cues from the 
patient presentation to trigger hypotheses, both logical criteria and a pseudo-probabilistic 
scoring scheme to confirm or eliminate hypotheses, and explicit differential links to revise 
hypotheses when discrepant information arose. Later versions introduced a simple model of 
time, categorizing both patient data and a hypothesis-oriented time line along the dimension: 
past, recent-past, now, near-future, future. Gratifyingly, this facility led unexpectedly to a 
simple but reasonable prognostic ability, as PIP could use current data to predict future 
instances of disease. Our interest in temporal reasoning has continued through the doctoral 
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work of Kohane [Koha86, Koha87], exploring temporal constraints in diagnostic reasoning; 
Russ [Russ90, Russ91], who designed a control structure that supports reasoning about 
unreliable streams of time-oriented data and applied it to diabetic ketoacidosis; and Haimowitz 
[Haim93, Haim93a], who studies trend detection in pediatric growth data and in ICU 
monitoring. Wu’s PhD in 1992 [Wu92] demonstrated dramatic speedups of classical 
associational diagnostic reasoning using two heuristic principles: problem decomposition to 
identify clusters of findings, and occasionally temporarily ignoring information 
distinguishing alternative diagnoses, thus containing the exponential explosion of 
intermediate diagnostic states. 

At the same time as PIP’s development, we created a program to advise on digoxin therapy, 
using a hybrid inference method that employed pharmacokinetic modeling to assess drug 
levels, but a clinically-derived experiential model that suggested how to titrate ideal doses 
given the patient’s clinical state, evidence of possible digitoxicity, and urgency of care. This 
program also served as the vehicle for several programs on explanation and justification. 
Perhaps the most interesting was Swartout’s PhD thesis [Swar83], in which he used an automatic 
programmer to generate the digitalis advisor from underlying medical knowledge and 
treatment principles, which then formed the basis for a sophisticated explanation capability that 
guaranteed consistency with the program’s actual operation. Other explanation work used 
sophisticated English language generation techniques to turn program fragments and causal 
models into comprehensible natural language. 

Our frustration with programs based on associational knowledge led, around 1980, to the 
first model-based medical reasoning programs. In Patil’s ABEL program [Pati81] we modeled 
the acid-base and electrolyte domain in terms of multiple levels of pathophysiologic detail. 
Then, for cases in which associational models led to discrepant predictions, the program could 
instantiate a deeper model to explore causal mechanisms that can explain the discrepancy. For 
example, a patient with independent sources of acidosis and alkalosis could exhibit a normal 
pH, a finding not predicted by either condition but consistent with their combination. Long's 
Heart Failure program (HF) [Long92, Long92a, Long94], addresses the complex treatment of 
patients with heart failure, providing both a diagnostic and therapy planning component. 
Diagnosis is based on an approximate probabilistic method that works over a network of 
clinically-significant causal concepts, and therapy prediction is based on predicting the 
influence of possible interventions in a complex feedback system by using signal-flow analysis 
techniques. HF has proven to be quite effective at diagnosis in certain subdomains, and 
remains under active development to augment its diagnostic acumen and to further develop 
and test its therapeutic side. 

Because hand-building programs is so difficult, we pursued the use of case-based experience 
to augment and make more efficient the operations of a model-based reasoner. Koton’s PhD 
project, Casey [Koto89, Koto89a], adapted past case solutions to new cases that were similar as 
judged by their causal similarity, given by HF’s causal models. J ang’s dissertation [J ang93] 
enhances this approach by decomposing cases to be learned into their causally-coherent subparts 
(again as determined by HF), thus matching parts of a new problem and assembling the parts 
into a globally consistent account. We have also studied various statistical learning and 
classification techniques applied to real-world data. 

Our colleagues at Tufts/NEMC have pioneered the application of decision analysis for 
individual patient cases [McNe82, Pauk75, Pauk87, Pauk88], and we have contributed via the 
development of computer-based tools and models. The Bunyan decision-tree critiquer [Well89], 
built in the mid-1980’s is an expert system that examines decision trees and critiques both gross 
and subtle errors. For example, it would note that a diagnostic test whose outcome does not 
influence any later decisions is not being modeled correctly. More subtle critiquing expertise 
could notice that some phenomenon is being modeled in greater detail on one branch than on 
another—a common but subtle modeling bias. Leong, in her doctoral thesis [Leon94], is 
completing a new tool to support reasoning about long-term outcomes of medical interventions 
by building semi-Markov decision models from a graphical and medically-meaningful 
treatment description. Szolovits has recently built a prototype genetic counseling program, 
Geninfer [Szol92], that uses Bayes network solution methods to perform risk calculations to 
estimate the probability of heritable diseases. This program is being readied for trials under 
NIH funding. He is also involved in more fundamental explorations of probabilistic 
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reasoning; with Andersen of Aalborg and Shachter of Stanford [Shac94], we have some new 
results on the relationship between cutset conditioning and clique-tree formation. 

Because much of medical knowledge is imprecise, we continue to explore qualitative 
descriptions of medical processes and to develop techniques that yield useful inferences from 
less detailed models. Kuipers began his work on QSIM [Kuip86] in our group in the mid-1980’'s, 
developing qualitative models of cardiovascular physiology. Sacks’ 1988 PhD [Sach90] explored 
the use of sophisticated state-space representations to get much stronger characterizations of 
some qualitativel y-described systems and extended these to derive probabilistic predictions with 
Doyle [Doyl91la]. Wellman’s 1988 PhD [Well90] introduced the qualitative probabilistic model, 
which abstracts from particular numerical dependencies to more generic concepts such as 
“positively influences” and “interacts synergistically with.” Although such models cannot 
make detailed tradeoff decisions, they provide very robust models that can be used to show 
dominance of whole classes of possible plans over others, and thus can greatly simplify 
planning in large plan spaces. Yeh in his 1990 PhD [Yeh90] explored a variety of inference 
methods to determine bounds on possible behaviors of probabilistically-defined systems. 

Doyle and Wellman continue to investigate suitable representations for individual 
preferences [Doyl91b, Doyl94, Well91, Well92]. Their characterization of “preference all other 
things being equal” provides a powerful formal tool for abstract reasoning, without requiring a 
fully-specified multi-attribute utility function. This work continues with theoretical 
investigations aimed at applying it to capture basic preference attitudes of the subjects of GA. 

We also have a long-term participation in knowledge representation efforts. Hawkinson 
and Szolovits worked in the mid-1970's on the OWL [Szol77] and BrandX [Szol81] representation 
schemes that provided great flexibility and opportunities to exploit linguistic analogies but 
suffered from a lack of semantic rigor. When current more restrictive KR systems were built 
in the 1980's, we tried to use KL/ONE to represent medical knowledge and found that too much 
expressive ability had been sacrificed for semantic cleanliness and computational efficiency 
[Haim88, Haim88a]. Doyle and Patil produced a major and influential critique of this trend 
for the KR community [Doyl91]. 

Long and Szolovits are both Fellows of the American College of Medical Informatics, and 
Doyle and Szolovits are both Fellows of the American Association for Artificial Intelligence. 

Our group has pursued a wide variety of research projects in diagnostic and therapeutic 
reasoning, we have made fundamental contributions to Al and to medical informatics, and we 
believe that we are uniquely well-situated with our collaborators to make fundamental 
advances toward our vision of the “Guardian Angel” approach to health care. 

As an illustration of the background of the group, we attach as an appendix a selected 
listing of reprints often requested by correspondents. 


Tufts/NEMC 


The faculty at the Division of Clinical Decision Making at the New England Medical Center 
have been developing decision support for health policy and for individual patients over the past 
two decades. They were the first physicians to apply decision theory to the care of individual 
patients. In a 1975 article, they described acquiring and using patient utilities in deciding about 
coronary bypass surgery for three patients with angina. They are acknowledged as the premier 
group in the area. Their software has become the standard for medical decision- and cost- 
effectiveness analyses. They have collaborated with faculty and supervised students at MIT- 
LCS for two decades and continue a close working relationship. 

Their interest in patient utilities dates back to the paper addressing the need for surgery in 
coronary artery disease. |n 1976, they developed models and techniques that allow patients to 
more fully participate in decisions about prenatal diagnosis. Both of these models have been 
extensively applied to individual patients over the past two decades, the latter to over 1500 
patients. In now classic articles in the New England J ournal of Medicine they describe the 
acquisition of patient preferences (utilities) in patients with lung cancer and cancer of the 
larynx, and in other publications describe the impact of preferences on both individual decision 
making and health policy. They have been developing platforms for the automated acquisition 
and delivery of patient preferences for the past five years. 

Although the group spans all of medicine in their clinical interests, they have had a 
particularly impressive publication record in cardiovascular disease, including coronary 
artery disease, valvular heart disease, cardiac arrhythmias and hypertension. They have been 
involved in multi-centered studies, developing decision support tools funded by the AHCPR, 
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with collaborators at Duke University, the University of Minnesota, the University of Manitoba, 
UCSF, and the New York State Department of Health. They were major participants in the 
recent Short-Term Mortality Conference on coronary surgery, held at Duke University, which 
emphasized the importance of patient specific factors such as co-morbidities. 

These investigators also have substantial interest in adult diabetes and have been the major 
modeling group for the Diabetes PORT, funded by the AHCPR. They are just completing an 
analysis of the treatment of foot infections in diabetics, an analysis showing the importance of 
patient preferences and co-morbidities. Their interest in AIDS and HIV disease extends back 
over six or seven years, including articles emphasizing the interpretation of testing in low 
risk populations and the early treatment of HIV positive individuals. 

Much of their theoretical work has involved the assessment of co-morbidities and their 
impact on survival, patient preferences, and decision making. Dr. Stephen Pauker, the 
director, is Professor of Medicine at Tufts University and a Fellow of the American College of 
Cardiology, the American College of Physicians, the American Heart Association and the 
American College of Medical Informatics. Dr. Mark Eckman is Associate Professor of 
Medicine at Tufts University and is a Fellow of the American College of Physicians and the 
American College of Medical Informatics. Dr. John Wong is an Assistant Professor of 
Medicine at Tufts University and is a Fellow of the American College of Physicians. 


Children’s Hospital 


Isaac S. Kohane first began to work on automated diagnosis as a doctoral student in 1985. He 
joined the Harvard Medical School faculty and the staff of Children’s Hospital in J uly, 1992. He 
holds a medical degree and practices pediatric endocrinology. 

His PhD was awarded for his research in artificial intelligence in medicine and for his 
work on the Temporal Utility Package [Koha87] and its application to medical diagnosis. Dr. 
Kohane currently spends 80% of his time on work in medical informatics. |!n 1991 he completed 
the implementation of an on-line medical chart (the Clinician’s Workstation—CWS) [Koha90] 
for the Division of Endocrinology. This system has now been in full operation for 3 years and 
provides on-line access to clinic notes, clinic measurements, demographics, pharmacy data, 
laboratory results, problem lists and reports from ancillary departmental systems (e.g. 
radiology). The CWS is currently being brought to the nephrology and nuclear medicine 
divisions at Children’s Hospital. Over the past year, Dr. Kohane designed and led the 
implementation of a data integration and display system for the Multidisciplinary Intensive 
Care Unit. Data-sets on diabetes monitoring from this integration effort were distributed over 
the Internet for use by participants in the Spring Symposium of the American Association for 
Artificial Intelligence on “Interpreting Clinical Data” in Palo Alto (co-chaired by Dr. Kohane). 

Dr. Kohane’s current research is in the investigation of computer representations and 
architectures for clinical event monitoring. He is particularly interested in monitoring 
pediatric populations for early detection of pathological processes. In collaboration with Ira 
Haimowitz at MIT, he has developed a system for early detection and diagnosis of pathology 
from on-line clinical data. He has helped conduct preliminary trials to validate the 
methodology, especially in the domain of growth and development. 

Dr. Kohane’'s clinical practice is split between general pediatric endocrinology and the care 
of patients with insulin-dependent diabetes mellitus (IDDM). Of the latter, he follows 
approximately 50 patients and supervises the care of another 50. He has conducted several 
clinical trials to study the growth and development of several populations including children 
with |DDM, with heart disease, with adrenal disorders, and children treated with bone-marrow 
transplantation for malignancy. 


Veterans Health Adm.: Boston Dev. Center 


The Boston Development Center is a field support unit serving the needs of senior VHA 
management located in Washington, DC. The BDC provides medical informatics support to 
improve the linkage of clinical processes, budget processes, and resource allocation processes. 
The BDC develops and maintains large relational databases that provide patient-specific data, 
including workload, and costing, as well as limited diagnostic and medical procedure 
information for all patients treated by the VHA, which maintains 172 medical centers, and 
many outpatient clinics, nursing homes, and domiciliaries. The VHA system provides 
approximately one million inpatient admissions and 45 million outpatient clinic stops 
annually. Approximately 2.5 million unique individuals are treated each year. 
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Dr. Michael L. Meistrell is chief of medical informatics at this center. He practiced as a 
thoracic surgeon, and did fellowships in medical decision making with Dr. Robert Beck at 
Dartmouth and Dr. Stephen Pauker at Tufts/NEMC. Dr. Meistrell is interested in working 
with us on the definition of the GA architecture, and will help to recruit physicians in the VA 
system for trials of our applications. 


International Business Machines Corp. 
Applications Solutions Institute, T. J. Watson Research Laboratory 


The Applications Solutions Institute at |BM’s T. J. Watson Research Laboratory is organized to 
re-establish IBM’s strong presence in the health care information business by developing and 
deploying new technologies based on open systems to solve real customers’ needs. IBM has 
developed a strategy for the development of clinical information systems in which several 
critical areas have been identified: (a) clinical repository and data modeling, (b) medical 
lexicon authoring tool and server, (c) application and work flow modeling tool and process 
manager, (d) clinical workstation and user interface, (e) communication and system 
interface, and (f) decision support. IBM/’s project with Kaiser Colorado was initiated in 1992, 
designed with the above architecture specification and the intention to expand into multimedia 
and image support, and to multimodal input technologies. 

The IBM group has also prototyped an individual patient medical record system. This 
prototype is based on object-oriented techniques, and provides a small, portable machine with 
about 500MB of storage on a disk, and data import/export capabilities to a number of platforms 
[Chan91]. 

Our group at MIT has been tracking the development of this IBM system and its deployment 
at Kaiser Colorado. We view many of these facilities as useful components of a reference 
implementation of GA prototypes. 

The group at Kaiser Colorado is also quite interested in the Guardian Angel concept, and 
has expressed an interest in participating after the IBM-developed clinical information system 
is installed. Today, part of the system is in alpha-test mode. Kaiser Colorado and IBM are 
currently developing a medical lexicon authoring tool. The schedule of the IBM-Kaiser 
Colorado effort matches very well with the proposed Guardian Angel schedule. We plan to 
pursue the Kaiser Colorado collaborative opportunity (with IBM) before we enter year two of the 
project, because it provides not only an excellent test-bed in addition to the VA, but also a 
significant point of leverage toward eventual adoption of our ideas by a major health care 
provider. 


Gensym Corporation 


Gensym is a small software corporation that provides intelligent real-time process control 
software to a world-wide client base. Its principal product, G2, is a system for developing and 
deploying complex applications that require continuous and intelligent monitoring, diagnosis, 
and control. It is designed for a wide range of real-time applications in such fields as process 
control, telecommunications, manufacturing, aerospace, medicine, finance, and robotics. 

G2 utilizes a distributed, client/server architecture. This architecture provides the ability to 
do the following: (a) Scan an application, as a human operator would, and focus on key areas 
when it detects potential problems or opportunities. (b) Reason about and control events in a 
continuously changing environment. (c) Respond to events when they occur (eg. without 
continually polling sensors). (d) Apply knowledge represented in multiple forms, e.g., rule 
based heuristics, procedures, graphical networks of objects, and dynamic or discrete-event 
models. (e) Apply this knowledge where appropriate, using object-oriented representations that 
closely model the actual domain. (f) Express and use relationships between objects. 
(g) Represent the permanent and transient aspects of an application. (h) Acquire information 
from any number of data sources, both local and remote. (i) Provide information to and 
respond to requests from users, both locally and at remote client nodes. (j) Communicate with 
other G2s and applications (for example, with external simulation programs). 

Over 1500 G2 licenses are installed worldwide. G2 is increasingly applied in 
pharmaceutical, biomanufacturing, and health-care applications. For example, G2 is being used 
in a clinical laboratory in Ontario that will process 15,000 blood samples per day. The system 
monitors and makes decisions on work flow, system trends and alarms; balances workload 
among multiple analyzers; releases normal results; and refers abnormal results for further 
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testing, human interpretation, etc. Gensym has considerable experience interfacing G2 to 
corporate databases. Gensym is interested in working with our project and shares our vision of 
how to influence the future of health care. 


Results, Products and Transferable Technology 


We plan to assure dissemination of our results and technology transfer in the following three 
ways: First, as is normal with research projects, we will publish papers and reports, give 
conference presentations, and encourage our students and colleagues to pursue research projects 
based on what we learn during the conduct of the proposed research. Second, we plan to develop 
both an architecture of Guardian Angel and reference implementations as applied to the 
specific medical areas we pursue. These will be made available to other researchers, and can 
form the basis for future projects and products. Third, through our collaborations with IBM, 
Gensym, New England Medical Center, the Children’s Hospital, Kaiser Colorado, and the 
Veteran’s Administration, we expect to imbue both industry and potential prime supporters of 
our approach with enthusiasm for GA. This enthusiasm will be based, we expect, on their 
successful cooperation in defining the GA architecture, helping to bring about its 
implementation, and observing the success of its applications. 

Our project is likely to produce interesting new scientific ideas as we address difficult 
problems of modeling and architecture, and as we challenge existing technologies and build 
new ones. Our strong emphasis on tailoring the actions of the GA to the needs and preferences 
of the patient will result in new insights into issues of patient modeling and the expression, 
elicitation and use of preference models. As we have often done in the past, we will continue to 
use the difficult challenges of medical reasoning and knowledge representation to test ideas of 
knowledge representation, which have often proven inadequate to the tasks posed by medical 
reasoning. Our emphasis on frequent and seamless communication and exchange of 
information will provide interesting models for the evolving national information 
infrastructure. Our use of knowledge representation and interchange languages developed in 
current knowledge-sharing efforts should also yield opportunities for testing and validation of 
these efforts. We also expect to apply existing methods and develop new expert systems 
techniques for incremental interpretation of data and for user modeling. Finally, if our beliefs 
about the importance of the Guardian Angel concept for medical care prove correct, we can 
achieve a significant improvement in the delivery of medical care. Even if the concept is 
worked out with only partial success, we will have identified a very important set of research 
problems for future attention. These results will be disseminated by traditional scientific 
publications. 

We also expect that the architecture we develop for GA, the reference implementations we 
build for our chosen application domains, and the tools we assemble and construct will form a 
valuable set of concepts and engineering artifacts that others may find useful. Because we plan 
to make available both a reference architecture and a set of reference implementations, 
potential adopters can choose whether to build new implementations based on the architecture or 
to adopt our reference implementations. To the extent possible, we would like to make the 
reference implementations available to others at little or no cost, but because they are likely to 
include components that are commercially developed, this may not be possible. We can 
guarantee for-fee availability of the reference implementation. We hope that our architecture 
will be adopted both by other researchers and by those more interested in building new 
applications. If interest warrants, we will establish a consortium between interested parties to 
promote and guide future development. 

A less tangible but very important result we hope to achieve is to generate a commitment 
among our partners and others who provide health-care services and health-care technologies to 
the principles of patient-centered computation and record keeping. American medicine is very 
likely to undergo a dramatic change with the introduction of government-mandated universal 
health-care coverage and with the growing emphasis on cost-effectiveness of care. In such a 
time of upheaval, we hope to be able to create a paradigm shift in the application of informatics 
techniques as well. Guardian Angel may be the right vehicle. 
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